5장자율적인 객체 = 스스로 정한 원칙으로 행동하는 객체객체가 행동하는 이유 = 다른 객체로부터 요청을 수신받았기때문 객체 B가 객체 A에게 목표 A를 수행하기 위해 행동 A를 하라고 하는 것은 자연스럽다.객체 B가 객체 A에게 목표 A를 수행하기 위해 행동 a,b,c,d를 순차 수행하라고 하는 것은 부자연스럽다.이 경우 객체 A는 목표 A를 위해 행동하는 것이 자유롭지 못하고 객체 B에 의존적이다. 메시지가 추상적이면 안된다.메시지는 어떻게가 아니라 무엇을 해야하는지 설명해야한다. (어떻게 = a,b,c,d, 무엇을 = A)메시지를 명시할 때 어떻게 수행될 지에대해 명시할 필요가 없다. 무엇이 실행되는지를 명시한다. 다형성= 동일한 메시지에 다르게 반응하는 것= 대체 가능성= 재사용 가능성= 확장이 가..

객체지향 개발 5대 원리 : SOLID S 단일 책임 O 개방, 폐쇠 L 다형성 I 인터페이스 분리 D Dependency injection 1장객체지향의 목표 : 목표를 달성하기 위한 협력과 맡은바 역할과 책임을 다하는 것객체지향의 시작 : 적절한 객체에게 적절한 책임을 할당하는 것 객체는 자율적이고 협력적이여야한다.협력적이란 것은 개방적이란 것이다. 자율적이란 것은 외부의 간섭받지않고 스스로 결정가능하다는 것이다. request = 메시지 request caller = senderrequest callee = recieverrequest 처리 = 메소드 '클래스' 지향 프로그래밍이 아니라 '객체' 지향 프로그래밍임을 유념해라.어떤 클래스가 필요한가가 아닌 어떤 객체가 어떻게 통신해서 협력할 것인가를 ..

클린 코드를 위한 주석 이름 안좋은 예시비고 부적절한 정보 변경 이력 시스템이 저장해주는 정보는 더이상 저장할 필요없다. 쓸모없는 정보 성의없는 주석 주석 처리된 코드 맘놓고 그냥 지워라. Git에서 복구하면 된다. 코드로 충분한 정보 add(3, 5) // 3+5 환경 이름안좋은 예시비고 한번에 build 가능해야한다 한번에 test 가능해야한다 함수 이름안좋은 예시비고 매개변수는 적을 수록 좋다 매개변수에 boolean을 넣지마라 사용자는 true 또는 false 로 호출하면 결과가 어떻게 달라지는지 짐작이 안간다. 애초에 이것이 존재한다는 것은 함수를 쪼갤수 있다는 증거다. 출력인수는 사용하지 마라 int num; scanf("%d", &num); scanf에 num을 넣는건 입력이 아니라 scan..

SerialDate : java.util.Date의 불편함을 해소하고자 만든 라이브러리 변경이력을 나타내는 주석은 더 이상 필요없다.주석을 HTML 태그를 사용해서 표시하지마라 명칭에 관한 고민어떤 기준을 기점으로 얼마나 ~가 지났는지를 표현하기에 Serial 은 적합한가? relative offset이 더 적합하다.Serial은 일련번호, 즉 식별 번호에 사용하기 적합하다. 옛날 프로그래밍에서 사용하던 기교를 피하라ex. Constant 클래스를 상속하게 해서 TARGET_CONSTANT에 접근할 때 Constant.TARGET_CONSTANT 와 같이 접근하는 것을 피하려던 기교.바람직하지 못하므로 enum을 써라. 독자적인 enum 소스파일을 만들어 사용하라. enum에는 toInt()와 같은 것이..

JUnit 리팩토링 사례 분석 이제는 더 이상 필요없는 접두어를 제거하자 지저분한 조건문은 메소드로 boolean 을 반환 받도록 분리하자 특정 메소드에 사용되는 함수들이 있다면해당 함수들의 사용 방식에 일괄성을 주자(모두 반환하는 데이터가 있게 하도록 하거나 모두 없게 하거나 하자) 숨겨진 시간 결합을 끊자. 숨겨진 시간 결합findA가 멤버변수 A를 찾아내서 할당하는 함수고,findB가 멤버변수 A를 이용해서 B를 찾아내는 함수라면,다음 코드는 숨겨진 시간 결합이 존재한다.findA();findB(); 아래와 같이 바꿔서 숨겨진 시간 결합을 깰 수 있다.A = findA();B = findB(A); 좀 더 개선하면 findB를 다음과 같이 고치고 findAAndB함수를 사용해라.public void ..

동시성 동시성과 깔끔한 코드는 양립하기 어렵다.그러나 동시성은 결합을 없애는 전략이다.무엇과 언제를 분리하기 때문이다. 동시성은 필요하다.동시성은 다소 부하가 생긴다.동시성은 코드도 더 짜야한다.동시성은 복잡하다.동시성은 버그를 재현하기 힘들다.동시성은 근본적인 설계 전략을 재고해야한다. 동시성 방어 원칙1. 단일 책임 원칙 -> 동시성 코드는 다른 코드와 분리하라2. 자료 범위 제한 -> 공유자료를 최대한 줄이고 캡슐화하라, synchronized로 임계영역을 보호하라3. 자료 사본 사용하기4. 스레드를 독립적으로 구현하라.5. 라이브러리를 이해하라. 스레드 환경에 안전한 컬랙션java.util.concurrent 패키지java.util.concurrent.atomic 패키지java.util.concu..