[2019.02.09] 클린 코드 (시스템, 창발성)

시스템

시스템 생성과 시스템 사용을 분리하라

아래는 이것을 실제로 적용하기 위한 기법들이다.

1. 초기화 지연

public SystemService getSystemService(){

if(systemService == null)

systemService = new SystemServiceImpl();

return systemService;

}

+ 객체가 필요할 때까지 객체 생성을 미룰 수 있다.

+ null을 반환하지 않는다.

- SystemServiceImpl 생성자에 의존적이다.

- SystemServiceImpl 가 적절한 기본값인지 모른다.

- 환경에 따라 SystemService를 다르게 줄경우 SRP 원칙에 위배된다.

2. Main 분리하기

＊메인 함수는 시스템에 필요한 객체를 생성만한다.

＊애플리케이션은 이 객체를 사용하기만 한다.

3. 팩토리 패턴 이용하기

＊Main 분리하기를 따라하되 애플리케이션이 객체의 생성 시점을 결정해야하는 경우 추상 팩토리 패턴을 사용한다.

＊메인 함수는 추상 팩토리의 Concrete를 생성한다.

＊애플리케이션은 추상 팩토리의 Abstract를 사용한다.

4. Dependecy Injection

결국 이 모든 과정은 애플리케이션이 객체를 생성하는 과정을 몰라도 되게 하여 사용하기 편리하게 하기 위함이다.

Spring에서 말하는 DI 가 추구하는 목표가 이것이다. 

(초판 2013년 기준)

xml으로 빈(객체)을 생성하고

애플리케이션은 XmlBeanFactory를 통해 빈을 불러와 사용한다.

관심사를 적절히 분리하지 못해 성장이 어려웠던 EJB 아키텍쳐 사례

아키텍쳐가 너무 복잡하고 추상화 레벨이 너무 높아 이해하기 어려웠다.

더불어 지나친 스펙 때문에 무겁고 단위테스트도 어려웠다.

시스템은 도메인 특화 언어가 필요하다.

표준이라는 이유만으로 쓰지말아라.

관심사를 생각해라.

※ POJO

---

창발성(Emergency)

설계 원칙

1. 모든 테스트를 실행해야한다.

2. 중복을 없애야한다.

3. 프로그래머 의도를 표현한다.

4. 클래스와 메소드 수를 최소로 줄인다.

왜 TDD가 좋은가? : 테스트가 가능하게 하려면 응집도는 높아지고 결합도는 낮아지므로

그러므로 테스트 케이스를 만들고 계속 돌려라