[Clean Code 정리] 시스템

Clean Code - 시스템

 

1. 시스템 제작과 시스템 사용을 분리하라

- 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 준비 과정 이후에 이어지는 런타임 로직으로 분리해야 한다.

- 관심사 분리가 필요하다.

 

 

1) 객체 생성과 비즈니스 로직인 혼합된 경우 : 초기화 지연 또는 계산 지연

def get_equipment_connector(self):
    if (self.__equipment_connector == None):
        self.__equipemnt_connector = EUVEquipmentConnector()
    return self.__equipment_connector

(1) 장점

- 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리 않고 어떤 경우에도 null 포인터를 반환하지 않는다는 장점

 

(2) 문제점

 a. 의존성

   - get_equipment_connector 메서드가 EUVEquipmentConnector와 생성자 인수에 명시적으로 의존한다.

 

 b. 테스트

   - EUVEquipmentConnector가 무거운 객체라면 단위 테스트에서 get_equipment_connector 메서드를 호출하기 전에 적절한 테스트 전용 객체를 equipment_connector 필드에 할당해야 한다.

   - 일반 런타임 로직에 객체 생성 로직을 섞어놓은 탓에 모든 실행 경로도 테스트해야 한다.

   - 책임이 객체 생성과 로직으로 단일 책임 원칙에 위배된다.

   - 현실적으로 한 객체 유형이 모든 문맥에 적합할 가능성이 있는지 따져봐야 한다.

   - 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.

 

(3) 결론

- 주요 의존성을 해소하기 위한 방식, 전반적이며 일관적인(단일 책임 원칙) 방식이 필요하다.

 

 

 

2. 의존 역전 원칙(DIP, Dependency Inversion Principle)

- 구현 클래스에 의존하지 말고 추상화된 것에 의존하도록 만들어라

 

 

1) Main 분리

- 생성과 관련되 코드는 모두 main이나 main이 호출하는 모듈에 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

- Main은 제어 흐름을 담당한다.

- Main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다.

- 애플리케이션 영역은 그저 객체를 사용할 뿐이다.

- 애플리케이션은 Main이나 객체가 생성되는 과정을 전혀 모른다.

 

 

2) Factory

- 팩터리의 목적은 DIP이다.

- 때로는 객체가 생성되는 시점을 애플리케이션 영역에서 결정해야할 수ㄷ 있다.

- 팩터리 패턴을 사용해 객체를 생성하는 시점은 애플리케이션이 결정하지만 생성하는 코드는 애플리케이션이 모르도록 한다.