엘레강트 오브젝트 Chapter1. 출생

September 10, 2021 - 2 minute read -
book elegant-object OOP

객체지향에 대해서 더 자세하게 공부하고 이해하고 싶어 이 책을 읽기 시작했다.
이 책의 저자는 단정적인 말투로 이야기를 하고 있기 때문에 읽는데 쉽지 않았지만 코드 품질을 위한 방향이므로 유연하게 받아 들여야겠다.


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

역시 이전 코드에 대해 많은 반성을 하게 되는 글이었다.
지금껏 주 생성자에서만 할당문 이외의 코드가 없게끔 신경썼지 부 생성자나 팩토리 메소드에서는 그러지 못했다. 모두 똑같이 인스턴스화를 위한 것이므로 다른 타입의 객체로 한번 더 감싸거나 객체 역할에 대해 다시 고민해봐야겠다.