코드를 작성하는 모든 부분은 유지보수와 관련이 있다는걸 항상 명심하자.
2-1 가능하면 적게 캡슐화하세요
- 4개 또는 그 이하의 객체를 캡슐화 할것을 권장하고 있으며 왜 최대 4개인지? 근거를 제시해주고 있다.
나의 느낀점
- 책이 말하는 내용은 너무 많은 필드를 포함하면 안되며 작게 나눠야 한다는 것을 강조하는 것 같았다. 하지만 그 필드의 개수를 4개로 딱 지켜야하는 규칙저럼 정해둔 부분은 좀 아쉬웠다.
- 작게 나눠서 분리하는 부분은 동의하는 말이지만 코드를 작성하는 사람이 유지보수성만 고려해서 잘 작성한다면 꼭 4개를 지킬 이유는 없을 것 같다.
2-2 최소한 뭔가는 캡슐화하세요
- 객체가 아무것도 없는 “무”와 아주 비슷한 어떤 것이라면 무언가라도 캡슐화를 해야한다고 권고하고 있는 것 같다.
나의 느낀점
- 이번 내용은 어떤 말을 하고 싶은건지 이해하기가 약간 어려운 부분이였다. 수정된 코드를 보고 난 이후에도 크게 어떤 부분이 개선이 된건지는 잘 모르겠다.
- 오히려 눈에 띈 부분은 수정된 코드 생성자 파라미터에 final 키워드가 있는 것을 보고 1-3 생성자에 코드를 넣지 말라 챕터의 내용이 떠올랏다. 생성자 파라미터에 final 키워드를 사용해서 넘어온 인자에 대한 값 변경 자체는 1차적으로 막을 수 있는 것 같아 좀 더 안전한 설계가 가능해 보였다.
2-3 항상 인터페이스를 사용하세요
- 객체들이 너무 강하게 결합된다면 객체들의 개수가 많아질수록 유지보수성에 큰 영향을 미친다.
- 즉 결합도를 낮추기 위해 인터페이스를 적극적으로 사용하자 !
나의 느낀점
- 동일한 인터페이스를 구현하는 여러 클래스들이 서로 다른 클래스를 쉽게 대처할 수 있어야 하며 느슨한 결합도를 유지하도록 하는 내용이 공감되는 부분이였습니다.
- 구현체에 의존하지 말고 인터페이스에 의존하도록 하자.
2-4 메소드 이름을 신중하게 선택하라
- 빌더는 명사, 조정자는 동사, 불린은 형용사를 활용해서 메서드 이름을 작성하는 것을 제시해주고 있다.
나의 느낀점
- 메서드 이름 짓는게 어떻게 보면 가장 어렵다고 생각이 들었는데 어느정도 가이드는 해준 것 같아서 나쁘지 않았다.
- 하지만 boolean형태는 개인적으로 is라는 키워드 정도는 많이 사용하고 있을 것 같다 라는 생각이 들며 is 키워드를 잘 사용해온 사람들이라면 크게 동의하지 못하는 내용이라는 생각이 들었다. 개인적으로 is 키워드를 오히려 붙여주는게 더 좋아보인다고 생각한다.