Memo

35page
가독성 높은 코드를 작성해야 하는 이유(소프트웨어 유지보수 비용이 높기 때문에)
커뮤니케이션에 초점을 맞춰서 프로그래밍을 하면 경제적으로도 효과가 높다. 소프트웨어 비용의 대부분은 소프트웨어가 개발된 후에 발생한다.
내 경험에 비춰봐도 기존 코드를 읽고 수정하는 데 걸린 시간이 코드를 새로 짜느라 걸린 시간을 압도한다.
따라서 내가 짜는 코드의 개발 비용을 줄이기 위해서는 이해하기 쉬운 코드를 작성해야 한다.

37page
프로그램을 최대한 단순화 하라. 의미없는 코드는 모두 제거하라. 설계 시에도 과도한 요소는 모두 빼고,
요구 사항을 분석해서 꼭 필요한 사항만을 뽑아내라. 과도한 복잡도를 제거하면 코드를 새로운 관점에서 바라볼 수 있다.

38page
(정말 필요할때 유연성을 얻는 패턴을 사용하고 패턴 남용을 경계하자)
유연성이 있으면서도 당장 이득을 얻을 수 있는 패턴을 사용하라. 당장 비용이 들어가지만,
앞으로 이득을 얻을 수 있을지 불확실한 패턴의 경우에는 일단 사용을 자제하는 편이 좋다.

39page
구현패턴의 근간이 되는 원칙
지역적변화 - 중복된 코드가 많으면 코드 수정이 어려워진다. 로직과 데이터를 함께 유지
대칭성 - add/remove와 같이 대칭성은 프로그램에서 일관된 방식으로 표현하는 통일성 -> 중복제거하기 쉬워짐
변화율 - 변화율이 다른 로직과 데이터는 분리

49page
구현 패턴은 어떻게 하면 사람들이 이해할 수 있는 코드를 작성할 수 있는지에 중점을 둔다.

53page
클래스
클래스 계층을 사용하면 코드를 읽기 어려워진다. 하위클래스를 이해하기 위해서는 상위클래스도 이해해야 하기 때문이다.
중요한 클래스에 대해서는 한 단어로 된 이름을 사용하는 것이 좋다
56page
보통 다단계 클래스 계층을 사용할 경우 위임을 통해 다단계 클래스 계층을 제거하는 편이 좋다
이름
상위 클래스: 부르기 쉬운 한 단어
2단계 클래스: 수식어 + 상위 클래스
3단계 클래스: 보통 위임으로 변경
-> 클래스 이름이 코드의 내용을 반영해야 한다

56page
인터페이스 vs 추상클래스
인터페이스를 통해 유연성을 얻을수 있는 경우에만 인터페이스에 비용을 지불해야 한다.
인터페이스: 구현변경은 쉬우나 인터페이스를 바꾸기는 쉽지 않다
(인터페이스에 가시성이 제공되면 좋겠다)

58page
인터페이스 이름: 구현클래스 이름이 중요하면 I prefix를 사용, 인터페이스나 상위클래스 바뀔수 있으면 간결한 이름 without I prefix

59page
널리 사용된 인터페이스를 수정하면 기존 구현이 마비된다. 인터페이스를 사용하면서도 기존 설계를 점진적으로 개선하려면 버전 인터페이스를 사용해야 한다.

추상클래스: 새로운 연산을 얼마든지 추가할 수 있다. 하나의 상속만 허용된다.

60page
버전 인터페이스
기존 인터페이스를 수정하지 않고 일부만 변경이 필요한 경우, 기존 인터페이스를 확장해서 신규 인터페이스를 만들고 해당 인터페이스를 사용하도록 수정
사용하는 곳에서는 downcasting하여 사용 -> 점점 많아지면 설계를 수정할 때가 되었다는 신호

66page
상속의 위험
구현상속의 경우,
일단 하위 클래스를 사용하면 되돌리기 쉽지 않다.
하위클래스를 이해하기 위해서 먼저 상위클래스를 이해해야 한다.
하위클래스가 상위클래스 구현에 의존할수 있어 상위클래스 수정이 위험해진다.

특히 치명적인 문제는 병렬 클래스 계층을 이용하는 경우, 클래스 계층간 암묵적 의존관계를 형성한다.

73page
조건문
조건문은 단순성과 지역성에서 장점(하나의 클래스만 수정)이 있지만, 광범위하게 사용되는 경우 문제가 될수 있다(안정성이 떨어진다)