Item13. 클래스와 멤버의 접근 권한은 최소화하라 Item 13 : 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 모듈과 그렇지 못한 모듈을 구별 짓는 가장 중요한 속성 하나는 모듈 내부의 데이터를 비롯한 구현 세부사항을 다른 모듈에 잘 감추느냐의 여부다. 요약1. 접근권한은 가능한 낮추라 2. 최소한의 public API를 설계한 다음, 다른 모든 클래스, 인터페이스, 멤버는 API에서 제외하라 3. public static final 필드를 제외한 어떤 필드도 public 필드로 선언하지 마라 4. public static final 필드가 참조하는 객체는 변경 불가능 객체로 만들라 정보은닉 모듈 사이의 의존성을 낮추자각자 개별적으로 개발, 테스트, 유지보수 등 수행다른 모듈에 영향을 끼치지 ..
오늘 이더리움 첫스터디를 했다. 우리 목표는 DAPP 개발이다. 첫 주제는 이더리움 코어에 대한 것이었다. 각자 파트를 맡아서 발표하는것도 좋겠지만, 같은 부분을 공부해서 궁금한 부분을 말하면 서로 그 부분을 긁어주는 방식으로 하는게 더 맞을것 같다고 생각했다. 스터디 하고 나서도 우리끼리 해결하지 못한부분이 너무 많다. 스터디에서 확실하게 익히지 못한 부분들과 답이 나오지않았던 부분을 기록하고, 해결해보즈아. 1. state데이터는 저장되어있나? level DB로 구성된다는건 유튜브보고 알았는데 이게 levelDB가 어디에있는것이며, 누가 갖고있는건지 잘 몰랐다. 5258900번째 블록 헤더에 state가 머클 값이 있을것인데.. 5258901번째 블록 헤더에 state에도 머클값이 있을것인데.. 이전..
페이스북을 하다가 김영기(화미주 대표)님의 영상을 봤다. 이분은 일주일에 하나씩 영상을 업로드 하신다. 한가지 주제를 가지고 사람들에게 좀더 생각하게끔 만드는?? 2016년에 센텀에서 강연을 해주셔서 그 때 뵜었는데, 엄청 열정이 넘치시는 분이다. 아무튼.. 어제 영상에서는 론과 밀턴 이야기가 있었다. 론처럼 그냥 계속 하면 낡은배로 계속 운행할테니... 밀턴처럼 내 계획을 되짚어보고 픽스해나가야 할 부분을 찾아보기로 했다. 좀 더 좋은 배를 만들자 1. 일찍 일어나기 일찍일어나기 위해 일찍 자는건 되는데 일어나지지가 않는다. 알람소리를 못듣는다... 얼또도 못하고있다.... 얼또 운영하시는 분은 12시 취침, 4시 기상이지만.. 나는 그정도는 아니더라도 얼또 글이라도 남겨보고싶은데!!!! 저녁시간에 커..
README 개방-폐쇄 원칙 (Open-closed principle) 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 기능을 변경하거나 확장할 수 있으면서 (개방)그 기능을 사용하는 코드는 수정하지 않는다. (폐쇄)-> 추상화와 매우 관련깊은 원칙인듯. 자쿰 몸통 / 팔몸통 : Main팔 : 기능 팔에는 개방(Open)몸통은 폐쇄(Closed) 기능 8개 추가 기능 추가시 몸통소스 건드리지말고 팔을 붙였다 뗏다하자~~!! 기능을 몸통에 다넣어버리면 서로 엉키고 엉켜서 한 기능이 다른기능에 의존적이게 짤지도 모릅니다.나중에 어떤 기능을 제거 했을 때 딸려오는 에러(?) 들이 있을지도 몰라요. 최소한 그런 불안감을 가지고 갑니다.코드 가독성..
Item12. Comparable 구현을 고려하라 Item 12 : Comparable 구현을 고려하라 (Consider implementing Comparable) Comparable 인터페이스를 구현하는 클래스의 객체들은 자연적 순서(natural ordering)를 갖게 된다. 자바 플랫폼 라이브러리에 포함된 거의 모든 value class는 Comparable 인터페이스를 구현한다. compareTo() 잘못짜면 비교 연산에 기반한 클래스들이 오작동할 수 있다. TreeSet이나 TreeMap 같은 sorted collection Arrays와 Collections같은 utility class 탐색과 정렬 알고리즘을 포함하는 class -> 당연.. compareTo가 이상하면 정렬이상하게 되겠찌..
뭔가 개강하면서 집중하지 못하는 것 같다. 내가 기존에 해왔던거를 지금은 잘 안한다. 새로운것 부터 하려고 하고 기존에 하던 것을 뒤로 미루고있는 것 같다. 방학때 하던 이펙티브자바나, OOP정리를 아직 끝내지 못했다. 헌데 지금 이더리움 코어만 파고있다... 이게 더 재밌고 나에게 맞아서 이것만 붙잡고 있는걸까? 그러면 다행이겠지만 나는 단지 새로운 것에 흥미를 느끼고 있을 뿐인것 같다. 이래버리면 결국 아무것도 완성시키지 못할텐데... 하다말고 하다말고.. 내가 어떤어떤것을 먼저 해야하는지.. 스케쥴을 다시 짜볼 필요가 있다.
Item10. toString은 항상 재정의하라 Item 10 : toString은 항상 재정의하라 (Always override toString) toString 일반 규약[JavaSE6] "사람이 읽기 쉽도록 간략하지만 유용한 정보를 제공해야 한다." toString을 잘 만들어 놓으면 클래스를 좀 더 쾌적하게 사용할 수 있다. 디버깅, 유지보수, 간단한 체크할 때 유용 기본 Object의 toString()은 className@해시코드 이기때문에 의미없다. {Jenny=PhoeNumber@163b91} {Jenny=(707) 867-5309} 어떤 toString이 더 유용하겠는가? 가능하다면 toString 메서드는 객체 내의 중요 정보를 전부 담아 반환해야 한다. 객체가 아주 크거나 문자열로 변..
Item09. equals를 재정의할 때는 반드시 hashCode도 재정의하라 Item 09 : equals를 재정의할 때는 반드시 hashCode도 재정의하라 (Always override hashCode when you override equals) Object 클래스 명세 일반 규약[JavaSE6] 프로그램 실행 중에 객체의 hashCode를 여러 번 호출하는 경우, equals가 사용하는 정보들이 변경되지 않았다면, 언제나 동일한 정수(integer)가 반환되어야 한다. 종료 후 다시 실행시 값이 같을 필요는 없다. equals() 가 같다고 판정한 두 객체의 hashCode 값은 같아야 한다. equals() 가 다르다고 판정한 두 객체의 hashCode가 같을 수도 있다. 이 경우 hash t..
