디자인패턴...Delegation 편

Delegation (위임)
   : 합성을 상속만큼 강력하게 만드는 방법.

장점
   - Runtime에 행동의 복합을 가능하게 하고, 복합하는 방식도 변경해 준다.

단점
   - Runtime이므로 동적이다.
   - 고도로 매개변수화되어 있으므로 정적인 구조보다 이해하기가 어렵다.


Delegation이 사용되는 디자인 패턴들
전적으로 Delegation사용
   - Mediator (중재자)
     : 객체 간의 교류를 중재하는 객체를 도입하여 중재자 객체가 다른 객체로 연산을 전달하도록 구현, 연산에 자신의 참조자를 함께 보내고 위임받은 객체가 다시 자신에게 메세지를 보내서 자신이 정의한 데이터를 얻어가게 함

   - Chain of Responsibility (책임 연쇄)
     : 한 객체에서 다른 객체로 고리를 따라서 요청의 처리를 계속 위임
     요청을 처음 받은 원본 객체에 대한 참조자를 포함

   - Bridge (가교)
     : 구현과 추상적 개념을 분리하는 패턴
     추상화와 특정 구현을 대응시키고 추상화는 단순히 자신의 연산을 구현에 전달

부분적으로 Delegation사용
   - State (상태)
     : 객체는 현재 상태를 표현하는 상태 객체에 요청의 처리를 위임

   - Strategy (전략)
     : 객체는 요청을 수행하는 추상화한 전략 객체에게 특정 요청을 위임

   - Visitor (방문자)
     : 객체 구조의 각 요소에 수행하는 연산은 언제나 방문자 객체에게 위임된 연산


결론
   : Delegation은 객체 합성의 극단적인 예로서, 고도로 표준화된 패턴에서 사용하는 것이 최상이다.



참조문헌
- GoF의 디자인패턴

객체지향 설계 핵심 척도 : SOLID

두문자	약어	개념
S	SRP	단일 책임 원칙 (Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다.
O	OCP	개방-폐쇄 원칙 (Open/closed principle) “소프트웨어 요소는 …… 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
L	LSP	리스코프 치환 원칙 (Liskov substitution principle) “프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
I	ISP	인터페이스 분리 원칙 (Interface segregation principle) “특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”[4]
D	DIP	의존관계 역전 원칙 (Dependency inversion principle) 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”[4] 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

:: References ::
https://ko.wikipedia.org/wiki/SOLID

디자인패턴...재사용방법 편)

재사용방법

1. 클래스 상속
 - 화이트박스 재사용이라고도 불리운다.
 - 장점
   ① 컴파일 시점에 정적으로 정의되고 프로그래밍 언어가 직접 지원하므로 그대로 사용
   ② 부모 클래스의 속성 및 함수를 재사용, 자식 클래스에서 재정의로 수정이 쉽다.

 - 단점
   ① 런타임 시점에 상속받은 부모 클래스의 구현을 변경할 수 없다.
   ② 부모 클래스에 종속되므로, 부모 클래스 구현에 변경이 생기면 자식 클래스도 변경해야 한다.
   ③ 상속 시 부모 클래스의 내부가 보이므로 캡슐화에 위반된다는 의견도 있다.

 - 해결책
   ① 추상 클래스를 상속받는다. 구현이 아닌 인터페이스를 상속받는 것이므로 유연하다.

2. 객체 합성
 - 블랙박스 재사용이라고도 불리운다.
 - 한 객체가 다른 객체에 대한 참조자를 얻는 방식으로 런타임에 동적으로 정의됨
 - 인터페이스 정의에 주의
 - 객체는 인터페이스에서만 접근하므로 캡슐화 유지, 종속성 감소


결론
GoF에서는
 "객체 합성이 클래스 합성보다 더 나은 방법이다."
라고 표현하고 있으며, 상속과 객체 합성이 적절히 조합되어야 완벽한 재사용이 된다고 한다.




참조문헌
- GoF의 디자인패턴

UML 클래스 다이어그램 정리

일반클래스 : 일반 글씨체

추상클래스 : 이탤릭체로 표현

참여사용자객체 :

1. 클래스 내의 멤버 변수 및 함수 표현

    public : +
    private : -
    protected : #
    default : ~

2. 클래스간의 관계 표현
    ⓐ Generalization (일반화 관계)
        - 상속관계, 자식클래스(인간)로부터 일반화시킨 부모클래스(동물)과의 관계를 표현한다.
    ⓑ Realization (실체화 관계)
        - 인터페이스를 구현하는 관계를 표현
    ⓒ Association (연관 관계)
        - 방향성이 존재한다. 단방향(->)과 양방향(-)이 있다.
        - Aggregation(집합)과 Composition(합성)이 있다.
          Aggregation은 서로 독립적이며, Composition은 종속적이다.
          Aggregation의 표현은 빈 마름모, Composition은 꽉 찬 마름모이다.
    ⓓ Dependency (의존 관계)
        - 말 그대로 의존하는 관계이므로 변경에 종속적이다.
          표현은 ---> 으로 한다.

독학을 하다가..

인터넷을 통해 독학을 하다보면 항상 느끼는 거지만...

모르는 것이 너무 많다 보니 꼬리에 꼬리를 무는 검색..

결국엔 A를 공부하다가 A의 시작 부분에서 꼬리를 따라 Z를 보다 하루가 끝나고 만다.

다음 날도 오늘은 꼭 A를 정복해야지 하면서 D를 보다가 끝난다.

그러다 보면 어느 순간 A를 손에서 놓고 J를 공부하는 나를 보고 깜짝 놀라기도 한다.

공부도 계획적이어야 능률적인 것 같다.

그 날 공부하는 목적을 적어놓고 어느 정도까지 마무리할 것인지를 계획하며,

순간 순간 모르는 것과 궁금한 것들은 바로 검색을 통해 공부하는 것보다,

따로 메모하여 목적이 완료된 후, 또는 다른 날 따로 계획을 잡아 알아보는 것이 좋겠다.

IT는 정말 방대하다.

모르는 것 투성이라, 인터넷 속에서 미아가 되버리는 일이 없도록 스스로 길라잡이를 만들어 놓자.

Eclipse Plugin - Amteras UML 설치

아래의 링크에서 Amateras UML을 다운받는다.
http://amateras.osdn.jp/cgi-bin/fswiki_en/wiki.cgi

다운받은 zip파일을 압축해제하여,
jar파일들을 Eclipse설치경로에서 plugin폴더 아래에 복사해 준다.
plugin폴더가 없는 경우엔 dropins폴더 아래에 복사해주면 된다.

이클립스 재실행하여 File->New->Other에서 Amateras카테고리가 보이면 설치 끝

GoF의 디자인 패턴

1. Creational Patterns(생성 패턴)
 - Abstract Factory(추상 팩토리)
 - Builder(빌더)
 - Factory Method(팩토리 메서드)
 - Prototype(원형)
 - Singleton(단일체)

2. Structural Patterns(구조 패턴)
 - Adapter(적응자)
 - Bridge(가교)
 - Composite(복합체)
 - Decorator(장식자)
 - Facade(퍼사드)
 - Flyweight(플라이급)
 - Proxy(프록시)

3. Behavioral Patterns(행동 패턴)
 - Chain of Responsibility(책임 연쇄)
 - Command(명령)
 - Interpreter(해석자)
 - Iterator(반복자)
 - Mediator(중재자)
 - Memento(메멘토)
 - Observer(감시자)
 - State(상태)
 - Strategy(전략)
 - Template Method(템플릿 메서드)
 - Visitor(방문자)

총 23개의 디자인 패턴.... 하나씩 풀어보자. 실전에 적용해보며~



참조문헌
- GoF의 디자인패턴