[Design] - 고찰.

 

 

System 디자인, 설계 등이 왜 필요할까 생각해 본다. 

 

프로그래머는 컴퓨터로 하여금 사람이 원하는 일을 시키도록 translate 작업을 하는 사람이다. 

 

그렇다면 기능구현을 하는데서 그 1차 책임이 종료된다고 할 수 있다. 

 

그렇다면 OOP, SOLID, Design Pattern등은 무엇 때문에 필요한가. 

 

Change Management, ?

Minimize release cost for the codes that have changes/new functionalities, ?

Efficiency

Look fancier?

Engineering egoism?

 

Clean Architecture 에서도 말하듯, 단위 코드 추가에 대한 최소한의 비용 유지가 아마도 가장 걸맞는 대답일 듯 싶다. 

그러나 이 답은 여전히 추상적이다. 

 

어떻게 측정 할 수 있겠는가.

어떤 것들이 유지되면, 만족되면 이것들이 지켜진다고 말할 수 있겠는가. 

 

이것이 바로 실제적으로 확인하고 가야 할 내용들이다. 

 

 

많은 경험과, 자료들을 근거로 하나의 추론을 해 본다.

모든 것들의 끝은 어디를 향해 있는가. 

무엇을 실제로 이루기 위해서 이런 모든 것들이 존재하는가. 

 

그 대전제는 바로,

이미 배포된 모듈/코드는 최대한 수정하지 않는다. 는 것이다.

 

그렇다면 추가 기능이나, 기존 기능의 변경은?

 

확장 (Extension)

 - 기존 코드가 유지되며, 새로운 객체가 추가될 뿐이다. 

 

동적 할당 (Allocation)

 - Dependency Inversion을 통해서, 외부 전달파라이터 등에 의해 행동을 맡는 객체가 변경된다. 

 

 

Aligning with SOLID principal.

 : Single Responsibility - 코드 수정의 억제와, 확장을 통한 기능추가를 위해 하나의 기능만 하도록 설계 한다.

 : Open Close - 확장에 의한 기능 추가가 이미 이것을 의미한다. 

 : Liskov Substitute - 역시 객체 그 자체 개념이 클리어하면 할수록 이것이 쉽다는 것을 의미한다.

 : Interface Segrigation - 인터페이스가 세분화 되어 있어야 client에서 적절하게 사용할 수 있다는 것으로, 역시 정리의 개념.

 : Dependency Inversion - 객체 할당에 따라 행동이 변화하도록 모듈 디자인. 

 

조금 더 정리하면, 

기존 코드 수정을 억제하기 위해 

Open Close나 Dependecy Inversion을 통해 기능을 수정 또는 확장하는데, 그를 위해서 

모듈이 Single Responsibility 하고 Liskov Substite하게 설계 되어야 하며, Interface가 Segrigation 되도록 하여 혼동을 피하여야 한다.

 

그렇다면 어떻게 이를 구체화 할 수 있을까?

 

역사를 거쳐 오면서 다수의 정형화된 패턴들의 모음을 찾았다. 

그것들을 디자인 패턴이라고 부른다.

 

생성형 패턴 

 ; Abstract Factory, Factory Method

    - 확장을 통해 객체를 생성하며 이를 통해 variation 한다.

    - 따라서 추가 대상이 생기면, 추가 확장 모듈을 만들면 된다. 

 ; Builder - 확장을 통해 세부 생성 제어. ( 동작은 TemplateMethod와 유사 )

 ; Singleton, Prototype - X 

 

구조형 패턴 

 ; Adapter, Bridge 

   - 두 모듈을 연결 할 때 사용

   - 기본 모듈 변경 억제 - 모듈 자체에 변화를 주지 않고, 추가 모듈을 둠으로써 그 기능만을 수행하도록 함. 

 ; Proxy

   - 기존 모듈을 이용해 추가 작업을 할 시. 

   - 로깅 추가, 캐싱, deferred loading, security 강화 등. - 기존 모듈의 변경 억제.

 ; Composite, Decorator, Facade - 여러 모듈을 구성하는 방법에 따른 차이.

 ; Flyweight - 구조보다는 기능에 가까움. 

 

 행동형 패턴 

  ; Command, Strategy  

   - 외부 객체 할당을 통한 행동 변화를 꾀하는 대표적인 패턴들

  ; Chain of Responsibility, Observer 

   - 객체간 이벤트 전달 방식을 정의

  ; Template Method 

    - 객체의 기능을 미리 정의하고, 확장을 통해 행동 변화를 꾀하는 방식. 

  ; Mediator 

   - Facade와 거의 동일 

  ; Iterator, Visitor 

   - 데이터 기반의 기존 객체를 그냥 두고, 해당 객체를 접근/기능 구현을 하는 방식.

  ; State, 

   - 객체의 책임 세분화와 각 객체간의 관계 재정의

 

 

그렇다면 무엇을, 어디에, 어떻게 적용하면 될 것인가?

 

실제세계의 문제에서 이들을 어떻게 적용할 지 사례별로 고민해 보자.