캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. (172p)
책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. 더 좋은 추상화가 더 쉽게 떠오른다. (176p)
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. (188p)
테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다. (190p)
한 클래스가 너무 많은 프로퍼티나 메서드를 갖고 있으면 고민하게 될 때가 많았다. 너무 많은 책임을 갖고 있어서 여러 클래스로 분리하는게 나을 것 같으면서도 분리하면 나중에 코드를 확인할 때 해당 클래스를 전부 살펴보는게 번거롭고 잘 나눠지지 않는다는 점에서 꺼려졌었다. 결국 이 모든게 각 클래스의 정확한 역할을 정의하지 못해서 발생한 문제가 아닌가 싶기도 하다. 역할을 명확히 한다면 재사용성 등에서도 큰 장점이 있으니 앞으로는 작은 코드량도 여러 방면에서 고민하고 작성해야겠다는 생각이 든다.