ologist`s blog2.0

설계에 있어 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다.
- Eric S. Raymond

실전 코드로 배우는 실용주의 디자인 패턴

Allen Holub / 사이텍미디어(희중당)

어쩌어쩌하다가 우연히 블로그에서 아이디/별명 검색UI를 보았다.

아이디와 별명이 다른 필드임에도 불구하고, 아이디 or 별명이라는 인터페이스가 존재를 했다. 그것도 서버쪽 인터페이스가 아니라 일반적으로 많이 사용할 만한 클라이언트쪽 인터페이스였다.

처음에 기획의도는 한방에 편하게 검색하는 것이라고 생각은 들지만, 개발을 할때 개발자는 한번도 생각을 해서 기획자와 협의를 통해서 인터페이스를 바꾸어야 했지 않나 싶다. or관련된 쿼리의 퍼포먼스저하 문제는 공인된(?) 사실중의 하나이다. 실질적으로 이런 조금만 것들이 모여서 어플리케이션의 성능을 저하시킨다.

기획적으로 조금만 UI를 다르게 생각해서 비슷한 효과를 볼수 있는 방법이 있을듯한데, 굳이 or로만 해결할수 있게 화면을 구성한 것은 아쉬운 일이다.

웹에서의 화면 구성은 중요한 이슈중의 하나이다. 기획자가 미쳐 놓치고 간 부분이 있다면, 개발자가 advice를 통해서 불필요한 부하를 일으킬 필요는 없지 않을까?  

개발을 할때도 고민하면서 창의적으로 업무를 수행할 필요가 있겠지만,  기획서, 스토리 보드를 확인할때도 좀더 고민하자.

객체지향의 기초
추상화 , 캡슐화 , 다형성 , 상속

객체지향의 원칙

• 바뀌는 부분을 캡슐화한다.
• 상속보다는 구성을 활용한다.
• 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
• 서로 상호작용을 하는 객체사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.
• OCP(Open-closed Principle) : 클래스는 확장에 대해서는 열려있어야 하지만, 코드 변경에 대해서는 닫혀 있어야 한다.
• 추상화된 것에 의존하라. 구상 클래스에 의존하지 않는다.
• 친한친구들하고만 이야기한다.
• 먼저 연락하지 마세요. 저희가 연락 드리겠습니다.
• 클래스를 바꾸는 이유는 한 가지 뿐이어야 한다.

디자인 원칙

• 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.(인터페이스와 구현부의 분리)
  : 달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 캡슐화합니다. 그러면 코드를 변경하는 과정에서 의도하지 않은 일이 일어나는 것을 줄이면서 시스템의 유연성은 향상시킬 수 있습니다.
  
• 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.
  
• 추상화된 것에 의존하도록 만들어라. 구상 클래스에 의존하도록 만들지 않도록 한다.
  
• 최소 지식의 원칙 : 정말 친한 친구하고만 얘기하라
  
• 객체지향 프로그래밍에서는 친구가 하나만 있는 것이 좋습니다.
  
• 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
  : 객체가 코드에 의해서 고정되지 않도록 , 어떤 상위 형식(supertype)에 맞춰서 프로그래밍함으로써 다형성을 활용해야 한다. 구체적으로 구현된 객체는 실행시에 대입하는 것 -> 상속을 쓸때 떠안게 되는 부담을 전부 떨쳐 버리고도 재사용성의 장점을 그대로 누릴 수 있습니다.
  

전문용어의 위력

서로 알고 있는 패턴 용어는 정말 막강합니다.

패턴을 이용하면 간단한 단어로 많은 것을 얘기할 수 있습니다.

패턴수준에서 이야기를 하면 디자인에 더 오랫동안 집중할 수 있습니다.

전문용어를 사용하면 개발 팀의 능력을 극대화할 수 있습니다.

전문용어는 신참개발자에게 훌륭한 자극제가 됩니다.

객체지향 패턴
스트래티지 패턴(strategy pattern) : 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지를 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수가 있다.

옵저버 패턴(Observer Pattern) : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신이 되는 방식으로 일대다(one-to-many) 의존성을 정의합니다.
ex) java.util.Observable

데코레이터 패턴(Decorator Pattern) :  객체에 추가 요소를 동적으로 더할 수 있습니다. 데코레이터를 사용하면 서브 클래스를 만드는 경우에 비해 훨씬 유연하게 기능을 확장할 수 있습니다 .
ex) java.io에 관련된 클래스들

팩토리 메소드 패턴(Factory Method Pattern) : 팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 됩니다. 팩토리 메소드 패턴을 이용하면, 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것

추상팩토리 패턴(Abstract Factory Pattern) : 추상 팩토리 패턴에서는 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상클래스를 지정하지 않고도 생성할 수 있습니다.

싱글턴 패턴(singleton pattern) : 해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 인스턴스에 접근할 수 있도록 하기 위한 패턴입니다.

커맨드 패턴(Command Pattern) : 커맨드 패턴을 이용하면 요구사항을 객체로 캡슐화 할 수 있으며, 매개변수를 써서 여러가지 다른 요구 사항을 집어 넣을 수도 있습니다. 또한 요청 내역을 큐에 저장하거나 로그로 기록할 수도 있으며, 작업취소 기능도 지원합니다.

어댑터 패턴(Adapter Pattern) : 한 클래스의 인터페이스를 클라이언트엗서 사용하고자 하는 다른 인터페이스로 변화합니다. 어댑터를 이용하면 인터페이스 호환성 문제때문에 같이 쓸수 없는 클래스들을 연결해서 쓸수가 있습니다.

퍼사드 패턴(Facade Pattern) : 어떤 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공합니다. 퍼사드에서 고수준 인터페이스를 정의하기때문에 서브시스템을 더 쉽게 사용할 수 있습니다.

템플릿 메소드 패턴(Template Method Pattern) : 메소드에서 알고리즘의 골격을 정의합니다. 알고리즘의 여러 단계중 일부는 서브클래스에서 구현할 수 있습니다. 템플릿 메소드를 이용하면 알고리즘의 구조는 그대로 유지하면서 서브클래스에서 특정 단계를 재정의할 수 있습니다.
ex)  알고리즘의 틀을 만들기 위한 패턴

이터레이터 패턴(Iterator Pattern) : 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있게 해주는 방법을 제공해 줍니다.

컴포지트 패턴(Composite Pattern) : 객체들을 트리구조로 구성하여 부분과 전체를 나타내는 구조로 만들 수 있습니다. 이 패턴을 이용하면 클라이언트에서 개별 객체와 다른 객체들로 구성된 복합 객체(Composite)를 똑같은 방법으로 다룰수 있습니다.

• 컴포지트 패턴이 클라이언트가 보기에 투명하게 작동하려면 복합 객체 내에 있는 모든 객체들의 인터페이스가 똑같아야 합니다. 인터페이스를 통일시키다가 보면 객체에 따라 아무 의미가 없는 메소드도 생길 수 있습니다.
  의미없는 메소드의 처리 방법
  
  1. 아무일도 하지 않거나 널 또는 false를 상황에 맞게 리턴하는 방법
  2. 예외를 던지는 방법

스테이트 패턴(State Pattern) : 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀수 있습니다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있습니다.

• 객체에 수많은 조건문을 집어넣는 대신에 사용할 수 있는 패턴

프록시 패턴(Proxy Pattern) : 어떤 객체에 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴

의존성 뒤집기 원칙에 위배되는 객체지향 디자인을 피하는데 도움이 되는 가이드 라인

• 어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 맙시다
• 구상 클래스에서 유도된 클래스를 만들지 맙시다.
• 베이스 클래스에 이미 구현되어 있던 메소드를 오버라이드하지 맙시다.

감상문 : OOP의 가장 이상적인 모델
인터페이스로 통신 및 접근을 하고, 구현체는 추상화되어 있어서 인터페이스 기반으로 설계를 한다. 객체를 생성하는 코드를 남발하지 않고, 한군데서 관리하도록 한다.
강력한 추상화,캡술화만이 OOP를 잘하는 지름길이다.



참고 서적
Head First Design Pattern - 에릭프리먼

Head First Design Patterns

케이시 시에라 / 한빛미디어

참고 article
Open-Closed Principle
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39134727,00.htm
인터페이스 분리의 원칙
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39139151-1,00.htm
리스코프 치환 원칙
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39137043,00.htm
단일 책임 원칙(Single Responsibility Principle)
http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39135552-1,00.htm

• fine-grained : 미세단위로 구분
• coarse-grained : 입도가 큰 단위로 구분
• 선택의 기준은 복잡도,크기,용도가 된다. 복잡도가 높고 부피가 큰데 반해 그 용법이 단순하다면, coarse-grained가 적합하다. 역으로 복잡도가 낮고 부피가 작으며 용법이 다양하다면 fine-grained가 적합하다.

• 응집도 : 하나의 클래스가 하나의 기능(책임)을 순도 높게 담당
  * 기능적 응집 - 일관된 기능들이 집합된 경우
  * 순차적 응집 - 한 클래스 내에 등장하는 하나의 소작업(메소드)의 결과가 다음 소작업의 입력으로 사용되는 관계(파이프라인 방식의 처리 체인 관계)
  * 교환적 응집 - 동일한 입력과 출력 자료를 제공하는 메소드들의 집합을 말하며, 팩토리 클래스는 전형적인 교환적 응집도가 높은 인터페이스를 갖는다.
  * 절차적 응집 - 순서적으로 처리되어야 하는 메소드들이 그 순서에 의해 정렬되는 응집관계
  * 시간적 응집 - 시간에 흐름에 따라 작업 순서가 정렬되는 응집관계
  * 논리적 응집 - 유사한 성격의 개체들이 모여 있을 경우를 말하며 java.io클래스들의 경우가 대표적인 예이다.
• 결합도 : 클래스간의 서로 다른 책임들이 얽혀 있어서 상호의존도가 높은 정도
  * 자료 결합 - 두 개 이상의 클래스가 매개변수에 의해서 결합 관계를 가지므로 낮은 수준의 결합도로 연관되는 경우
  * 스탬프 결합 - 자료 결합의 경우에서 매개변수 일부만을 사용하는 경우
  * 제어 결합 - 두 클래스간이 제어 이동이 매개변수를 이용하여 사용되는 경우
  ex) Command Pattern

• Extract Class는 혼재된 각 책임을 각각의 개별 클래스로 분할하여 클래스 당 하나의 책임만을 맡도록 하는 것이다. 여기서 관건은 책임만 분리하는 것이 아니라 분리된 두 클래스간의 관계의 복잡도를 줄이도록 설계하는 것이다.
• 만약 Extract Class된 각각의 클래스들이 유사하고 비슷한 책임을 중복해서 갖고 있다면 Extract Superclass를 사용할 수 있따. Extract class된 각각의 클래스들의 공유되는 요소를 부모 클래스로 정의하여 부모 클래스에 위임하는 기법이다.. 따라서 각각의 Extract Class들의 유사한 책임들은 부모에게 명백히 위임하고 다른 책임들은 각자에게 정의할 수 있다

산탄총 수술의 냄새는 하나의 책임이 여러 클래스에 분산되어 있기 때문에 발생한다.
특히 설정 정보, 로깅, DB처리에서 발생하기 쉽다.

핵심 리팩토링 기법과 책임 분배
: 할 수만 있다면, '사후 대처'보다는 '사전 예방'이 더 좋은 해결책이다.

SRP를 적용하면 클래스들의 숫자가 늘 수는 있다. 하지만, 클래스 숫자의 증가가 프로그램 복잡도 증가와 비례하는 것은 아니다. 오히려 SRP를 잘 따르는 프로그램은 절절한 책임 분배로 인해 클래스 숫자와 프로그램의 복잡도가 반비례하는 경향이 있다고도 할 수 있게 된다.

실제로 단순한 것이 위대한 것이다. 그리고 이 단순함의 중심에는 단일 책임의 원칙이 있다

• 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려 관계가 더 복잡해져서 설계를 망치는 경우가 있다. 설계자의 좋은 자질 중 하나는 이런 크기 조절과 같은 갈등 상황을 잘 포착하여 비장한 결단을 내릴 줄 아는 능력에 있다.
• 확장을 보장하는 open모듈 영역에서 예측하지 못한 타입을 만났을 때 인터페이스를 변경하려는 안과 어댑터를 사용하려는 안 사이에서 갈등하게 된다. 보통 후자를 선택한다. 한번 정해진 인터페이스는 시간이 갈수록 사용하는 모듈이 많아지기 때문에 바꾸는데 엄청난 출혈을 각오해야 한다. 즉, 인터페이스는 가능하면 변경해서는 안된다. 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요하다. 물론 과도한 작업은 불필요한 작업을 만든다. 설계자는 적절한 수준의 예측 능력이 필요한데, 설계자의 또 하나의 자질은 예지력이다
• 인터페이스 설계에서 적당한 추상화 레벨을 선택하는 것이 중요하다. 추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징이다.