소트웍스 앤솔로지에서 소개되는 객체지향 생활 체조 원칙 간략 정리

1. 한 메서드에 오직 한 단계의 들여쓰기만 하자

• 이를 위해서 Extract method를 적극적으로 사용해서 가독성을 증가시키자

2. else 예약어를 쓰지 않는다

• early return 방식으로 else를 회피하자 → 가독성 증가

  • optimistic 방식의 if조건보다는 defensive한 if조건을 사용해서 else문을 피하자 (기본 시나리오를 if 조건으로 지정하고, 충족이 안되면 오류 상태를 반환하도록)

3. 모든 원시값과 문자열을 포장하자

• Primitive obsession 안티패턴을 피하기 위해 모든 primitive 값들을 wrapping 하자 → VO로 만들자

  • Money, Time 등…

  • Primitive Obsession: 기본 데이터 유형을 지나치게 사용하거나, 불필요하게 복잡한 데이터 구졸ㄹ 사용해서 코드를 작성하는 패턴 → 복잡성 증가, 유지보수 어려워짐

    → class, struct, enum 등의 데이터 타입을 이용해서 코드 가독성과 유지보수성을 향상시키자

4. 한 줄에 점을 하나만 찍자

• 메서드 호출을 연쇄적으로 연결해선 안된다.

• law of demeter에 따라 한 객체가 알아야하는 다른 객체를 최소한으로 유지한다(인접한 친구에게만 말을 걸어라)

• Builder 패턴(메서드 체인 패턴)을 사용할 때는 적용되지 않음

5. 줄여쓰지 않는다(축약 하지말기)

• 충분히 기능, 목적 설명이 가능한 네이밍을 붙이자

• 적절한 네이밍 방법 →https://williamdurand.fr/2012/01/24/designing-software-by-naming-things/

  • 애플리케이션을 만들 때… UML 다이어그램이 있다고 가정하면

    1. 관심사를 분리함(ex. MVC 패턴, layered architecture, DDD 등의 기준을 두고)

    2. 컴포넌간의 상호작용을 고민하면서 네이밍한다. 이 때 구성요소 간에 사용할 수 있는 인터페이스를 식별함

    3. 네이밍이 애매할 때는 이 클래스의 존재가 타당한지, 더 분리할 수 있을지 고민한다

• github 등의 다른 좋은 프로젝트의 네이밍을 참고하자. JPA, spring 프로젝트 내부 패키지명에서도 정답을 찾을 수 있음 ex) JPA에서 CRUDRepository 인터페이스의 findById 같은 메서드명

6. 모든 엔티티를 작게 유지하자

• 하나의 클래스는 50줄을 넘기지 말자

• 하나의 패키지에는 10개 이상의 파일을 담지 말자

• 하나의 클래스가 100~150줄을 넘어가면 분명 분리할 수 있을 것

7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 말자

• 이를 잘 지키면 응집도와 캡슐화의 수준을 높일 수 있음

8. 일급 컬렉션을 쓰자

• 일급 컬렉션: 컬렉션을 포함하는 해당 class는 컬렉션을 제외한 다른 멤버변수를 포함하지 않음

  • ex) Unit이라는 하나의 클래스가 있고, 이를 이용해서 LIst<Unit> 단위로 사용하는 Units는 일급컬렉션이다. 이런 식으로 구현을 하면, 일급컬렉션의 public API를 이용해서 유저에게 일부의 기능만 사용하도록 할 수 있다

9. getter/setter, 프로퍼티를 쓰지 말자

• getter 까지는 괜찮아도 setter는 절대 쓰지 말자 - JavaBean 규약에 따라 작성된 자바 클래스