객체지향에 대해서 더 자세하게 공부하고 이해하고 싶어 이 책을 읽기 시작했다.
이 책의 저자는 단정적인 말투로 이야기를 하고 있기 때문에 읽는데 쉽지 않았지만
코드 품질을 위한 방향이므로 유연하게 받아 들여야겠다.
1.1 -er로 끝나는 이름을 사용하지 마세요
클래스는 객체의 팩토리다
java
에서new
연산자는 강력하지 않지만 팩토리 패턴과new
연산자는 같은 개념이다.- 필요할 때 객체를 꺼내쓰고 필요하지 않은 객체를 반환하는 저장소 또는 웨어하우스로 클래스를 바라보자.
- 클래스를 객체의 템클릿으로 보면 클래스의 개념을 낮추는 것이다.
무엇을 하는지가 있는지가 아니라 무엇인지 생각하고 클래스명을 지어야 한다
-er
또는-or
로 지어진 이름은 잘못 지어진 것이다.(computer 같이 의미가 정착된 단어는 제외)- 객체는 데이터를 다루기 위한 단순 연결장치가 절대 아니다. 데이터들의 대표자로 자립적인 엔티티이다.
Review
이 글을 읽고 이제까지 객체의 역할만 생각했지 클래스명을 짓는데 편법을 사용했던 것 같다.
읽으면서 Calculator
, Requester
등 이제까지 -er
또는 -or
를 붙여서 지었던 클래스들이 생각났다.
이 객체들이 무엇인지 다시 생각하게 되는 계가기 됐고 다음부터 이 원칙을 지키면서 클래스명을 신중하게 지어야 겠다.
1.2 생성자 하나를 주 생성자로 만드세요
생성자의 수가 메서드보다 많도록 클래스를 설계 해야 한다
- 한 클래스에는 2~3개의 메서드와 5~10개의 생성자가 있는 것이 적당하다. (근거는 없음)
- 생성자가 많아질수록 클래스를 유연하게 사용할 수 있다.
- 메서드가 많아질수록 단일 책임 원칙(Single Responsibility Principle)을 위반하기 쉽다.
주 생성자에 초기화 로직을 넣고 다른 부 생성자는 주생성자를 호출하도록 한다
- 모든 부 생성자에서 주 생성자를 쉽게 찾을 수 있다면 유지보수가 편하다.
(ex. 유효성 검사 로직이 한곳에만 있으면 됨 -> 중복제거) - java 생성자에서는
this
사용전에 인스턴스 메서드를 사용할 수 없으므로static
을 이용하자. - ‘하나의 주
constructor
와 다수의 부constructor
(one primary, many secondary)’
Review
머릿 속에서 정리 되지 않고 생각만 해보던 것이었는데 이 내용을 보고 확신을 갖게 되었다.
다만, 이 글에서는 생성자 얘기만 했지만
하나의 private
주 생성자를 두고 1.1에서 얘기한 정적 팩토리 메소드를 이용한다면 더 좋을 것 같다.
1.3 생성자에 코드를 넣지 마세요
‘인자에 손대지 말라(don`t touch the arguments)’
객체 초기화에는 코드가 없어야 하고 인자도 건드리지 마라 (오직 할당문)
- 객체 인스턴스화는 객체를 만드는 일만 해야 한다.
- 로직이 필요하면 다른 타입 객체로 감싸거나 가공되지 않은 형태로 캡슐화하자.
- 생성자에 코드가 들어가면 실행여부를 제어할 수 없어 최적화가 불가능.
- 데이터에 대한 요청이 있을 때, 파싱해서 주도록 한다.
(매번 파싱되는 것이 불편하다면 데코레이터를 이용하여 파싱 결과를 caching 하도록 하자.)
Review
역시 이전 코드에 대해 많은 반성을 하게 되는 글이었다.
지금껏 주 생성자에서만 할당문 이외의 코드가 없게끔 신경썼지 부 생성자나 팩토리 메소드에서는 그러지 못했다.
모두 똑같이 인스턴스화를 위한 것이므로 다른 타입의 객체로 한번 더 감싸거나 객체 역할에 대해 다시 고민해봐야겠다.