JustinLog: 2월 2016

2016년 2월 26일 금요일

GoF의 디자인 패턴 - Composite

Structural Patterns(구조 패턴) :: Composite(복합체)

구분
객체 구조 (Object Structural)

의도
- 부분과 전체의 계층을 표현하기 위해 객체들을 모아 트리 구조로 구성한다. 사용자로 하여금 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 하는 패턴이다.

포인트
- 기본 클래스와 이들의 컨테이너를 모두 표현할 수 있는 하나의 추상화 클래스를 정의하는 것

사용시기
- 부분-전체의 객체 계통을 표현하고 싶을 때
- 사용자가 객체의 합성으로 생긴 복합 객체와 개객의 객체 사이의 차이를 알지 않고도 자기 일을 할 수 있도록 만들고 싶을 때, 사용자는 복합 구조(Composite Structure)의 모든 객체를 똑같이 취급하게 된다.

장점과 단점
- 기본 객체와 복합 객체로 구성된 하나의 일관된 클래스 계통을 정의한다. 기본 객체는 더 복합적인 객체들에 속해 있을 수 있다. 물론 이 복합 객체 역시 다른 것에 속해 있는 것일 수 있다. 그러나 사용자 코드는 일반화된 상위 개념의 객체를 조작하는 방식으로 프로그래밍하면, 런타임 기본 객체와 복합 객체를 구분하지 않고 일관되게 프로그래밍할 수 있게 된다.
- 사용자의 코드가 단순해진다. 사용자 코드는 복합 구조이나 단일 객체와 동일하게 다루는 코드로 작성되기 때문이다. 즉, 사용자는 객체의 특성이 복합 구조인지 단일 구조인지조차 모르고 개발할 수 있다. 이런 구분이 필요치 않으므로 개발자의 코드에 "꼬리표-case-문장" 스타일의 함수를 쓸 필요가 없어지므로 코드가 단순해진다.

- 새로운 종류의 구성요소를 쉽게 추가할 수 있다. 새롭게 정의된 Composite나 Leaf의 서브클래스들은 기존에 존재하는 구조들과 독립적으로 동작이 가능하게 된다. 그러므로 새로운 요소가 추가되었다고 해서 사용자의 프로그램이 변경될 필요는 전혀 없다.

- 설계가 지나치게 범용성을 많이 가진다. 새로운 요소를 쉽게 추가할 때의 단점은 복합체의 구성요소에 제약을 가하기 힘들다는 것이다. 가끔 복합체가 오직 한 개의 구성요소만 가졌으면 할 때가 있다. Composite클래스만으로 타입 시스템을 통해 이런 제약을 가할 수 없다. 런타임 점검이 들어가야 한다.

구현의 유의점
1. 포함 객체에 대한 명확한 참조자
2. 구성요소 공유
3. Component 인터페이스를 최대화
4. 자식을 관리하는 연산 선언
5. 컴포넌트가 컴포넌트의 리스트를 구현할 수 있을까?
6. 자식 사이의 순서 정하기
7. 성능 개선을 위한 캐싱(Caching)
8. 누가 구성요소를 삭제하는 책임을 질까?
9. 구성요소를 저장하기 위해 가장 적당한 데이터 구조는?

관련 패턴
구성요소-부모 간의 연결은 책임 연쇄 패턴에서 많이 사용되는 예이다.
장식자 패턴은 자주 복합체 패턴과 함께 사용된다. 이 두 패턴이 함께 사용될 때는 둘 다 동일한 하나의 부모 클래스를 상속받게 된다, 따라서 장식자는 Add(), Remove(), GetChild()와 같은 연산을 통해서 Component의 인터페이스를 지원해야 한다.
플라이급 패턴으로 구성요소의 공유 방법을 얻을 수 있다. 단, 공유되는 구성요소의 보무는 참조할 수 없다.
반복자 패턴을 이용하면, 구성요소를 순회하는 방법을 얻을 수 있다.
방문자 패턴을 이용하면, 이 패턴을 사용하지 않을 때 Composite와 Leaf클래스에 걸쳐 분산될 수 있는 행동을 국소화시킬 수 있다.

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

2016년 2월 25일 목요일

GoF의 디자인 패턴 - Bridge

Structural Patterns(구조 패턴) :: Bridge(가교)

구분
객체 구조 (Object Structural)

의도
- 구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 한다.

다른이름
핸들/구현부(Handle/Body)

사용시기
- 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때, 이를테면, 런타임에 구현 방법을 선택하거나 구현 내용을 변경하고 싶을 때
- 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때, 이 때, 가교 패턴은 개발자가 구현을 또 다른 추상적 개념과 연결할 수 있게 할 뿐 아니라, 각각을 독립적으로 확장 가능하게 한다.
- 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때, 즉, 추상적 개념에 해당하는 클래스를 사용하는 코드들은 구현 클래스가 변경되었다고 해서 다시 컴파일되지 않아야 한다.
- 클래스의 구현과 속성에 대한 모든 표현 방식이 완전하게 은닉되도록 할 때
- 클래스의 상속 계통에서 클래스 수가 급증하는 것을 방지하고자 할 때

- 여러 객체들에 걸쳐 구현을 공유하고자 하며, 또 이런 사실을 사용자 쪽에 공개하고 싶지 않을 때

장점과 단점
1. 인터페이스와 구현 분리
2. 확장성 제고
3. 구현 세부 사항을 사용자에게서 숨기기

구현의 유의점
1. Implementor 하나만 둔다.
2. 정확한 Implementor 객체를 생성한다.
3. Implementor를 공유한다.
4. 다중 상속을 이용한다. (진정한 의미의 Bridge패턴이 될 순 없다.)

관련 패턴
Abstract Factory(추상 팩토리) 패턴을 이용해서 특정 Bridge(가교)를 생성하고 복합할 수 있도록 한다.
Adaptor(적응자) 패턴은 서로 관련이 없는 클래스들이 함께 동작하게 만드는 쪽에 특화시켜 만든 패턴이다. 이 패턴은 대개 각 클래스의 설계가 끝난 후에 적용된다. 한편, Bridge(가교) 패턴은 설계 단계 초기에 투입되어 추상화 및 구현이 독립적으로 다양화되도록 만드는 데 쓰인다.

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

2016년 2월 24일 수요일

GoF의 디자인 패턴 - Adapter

Structural Patterns(구조 패턴) :: Adapter(적응자)

구분
클래스, 객체 구조 (Class, Object Structural)

의도
- 클래스의 인터페이스를 사용자가 기대하는 인터페이스 형태로 적응(변환)시킨다. 서로 일치하지 않는 인터페이스를 갖는 클래스들을 함께 동작시킨다.

다른이름
- 래퍼(Wrapper)

사용시기
- 기존 클래스를 사용하고 싶은데 인터페이스가 맞지 않을 때
- 아직 예측하지 못한 클래스나 실제 관련되지 않는 클래스들이 기존 클래스를 재사용하고자 하지만, 이미 정의된 재사용 가능한 클래스가 지금 요청하는 인터페이스를 꼭 정의하고 있지 않을 때, 다시 말해, 이미 만든 것을 재사용하고자 하나 이 재사용 가능한 라이브러리를 수정할 수 없을 때
- [객체 적응자(object adapter)만 해당] 이미 존재하는 여러 개의 서브클래스를 사용해야 하는데, 이 서브클래스들의 상속을 통해서 이들의 인터페이스를 다 개조한다는 것이 현실성이 없을 때, 객체 적응자를 써서 부모 클래스의 인터페이스를 변형하는 것이 더 바람직함.

장점과 단점
1. 클래스 적응자(Class Adapter)
- Adapter클래스는 Adaptee클래스를 Target클래스로 변형하는데, 이를 위해서 Adaptee클래스를 상속받아야 하기 때문에, 하나의 클래스와 이 클래스의 모든 서브클래스들을 개조할 때라면 클래스 적응자 방식을 사용할 수 없다. 즉, Adapter는 명시적으로 Adaptee를 상속받고 있을 뿐 Adaptee의 서브클래스들을 상속받는 것은 아니므로, Adaptee의 서브클래스에 정의된 기능들을 사용할 수 없다.
- Adapter클래스는 Adaptee클래스를 상속하기 때문에 Adaptee에 정의된 행동을 재정의할 수도 있다.
- 한 개의 객체(Adapter)만 사용하며, Adaptee로 가기 위한 추가적인 포인터 간접화는 필요하지 않다.

2. 객체 적응자(Object Adapter)
- Adapter클래스는 하나만 존재해도 수 많은 Adaptee클래스들과 동작할 수 있다. 왜냐하면 Adapter객체가 포함하는 Adaptee에 대한 참조자는 Adaptee의 인스턴스를 관리할 수도 있고, Adaptee 클래스를 상속받는 다른 서브클래스들의 인스턴스도 관리할 수 있기 때문이다. 그러므로 하나의 Adapter클래스로 모든 Adaptee클래스와 이를 상속받는 서브클래스 모두를 이용할 수 있게 된다.
- Adaptee클래스의 행동을 재정의하기가 매우 어렵다. 이것을 위해서는 Adaptee클래스를 상속받아서 새로운 서브클래스를 만들고 Adapter클래스는 Adaptee클래스가 아닌 Adaptee클래스의 해당 서브클래스를 참조하도록 해야 한다.

구현의 유의점
1. Adapter클래스가 실제 적응 작업을 위해 들여하는 작업은 얼마나 되나?
2. 대체 가능(Pluggable) 적응자 - 위임을 사용하자

관련 패턴
Bridge패턴은 Object Adapter와 클래스 구조가 유사하나 그 사용 목적이 다르다.
Bridge패턴은 서로 다른 구현이 만족할 추상 개념을 분리하여 서로에게 영향을 주지 않고 각각 확장할 수 있도록 하려는 것이고, Adapter패턴은 존재하는 객체의 인터페이스를 변경하려는 것이다.

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

GoF의 디자인 패턴 - Structural Patterns

Structural Patterns(구조 패턴)

의도
- 인터페이스나 구현을 복합하는 것이 아니라 새로운 기능을 실현하기 위해 객체를 합성하는 방법을 제공한다.

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

GoF의 디자인 패턴 - Singleton

Creational Patterns(생성 패턴) :: Singleton(단일체)

구분
객체 생성 (Object Creational)

의도
- 오직 한 개의 클래스 인스턴스만을 갖도록 보장하고, 이에 대한 전역적인 접근점을 제공한다.

사용시기
- 클래스의 인스턴스가 오직 하나여야 함을 보장하고, 잘 정의된 접근점(access point)으로 모든 사용자가 접근할 수 있도록 해야 할 때
- 유일한 인스턴스가 서브클래싱으로 확장되어야 하며, 사용자는 코드의 수정없이 확장된 서브클래스의 인스턴스를 사용할 수 있어야 할 때

장점과 단점
1. 유일하게 존재하는 인스턴스로의 접근을 통제한다.
2. 이름 공간(namespace)을 좁힌다.
3. 연산 및 표현의 정제를 허용한다.
4. 인스턴스의 개수를 변경하기가 자유롭다.
5. 클래스 연산을 사용하는 것보다 훨씬 유연한 방법이다.

구현의 유의점
1. 인스턴스의 유일함을 보장해야 한다.
2. Singleton 클래스를 서브클래싱한다.

관련 패턴
많은 패턴이 Singleton패턴으로 구현될 수 있다.

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

GoF의 디자인 패턴 - Prototype

Creational Patterns(생성 패턴) :: Prototype(원형)

구분
객체 생성 (Object Creational)

의도
- 원형이 되는 인스턴스를 사용하여 생성할 객체의 종류를 명시하고, 이렇게 만든 견본을 복사해서 새로운 객체를 생성한다.

사용시기
- 인수턴스할 클래스를 런타임에 지정할 때
- 제품 클래스 계통과 병렬적으로 만드는 팩토리 클래스를 피하고 싶을 때
- 클래스의 인스턴스들이 서로 다른 상태의 조합 중에 어느 하나일 때
- 미리 원형으로 초기화해 두고, 나중에 이를 복제해서 사용하는 것이 매번 필요한 상태 조합의 값들을 수동적으로 초기화하는 것보다 더 편리하다.

장점과 단점
1. 런타임에 새로운 제품을 추가하고 삭제할 수 있다.
2. 값들을 다양화함으로써 새로운 객체를 명세한다.
3. 구조를 다양화함으로써 새로운 객체를 명세할 수 있다.
4. 서브클래스의 수를 줄일 수 있다.
5. 클래스에 따라 동적으로 응용프로그램을 설정할 수 있다.

구현의 유의점
1. 원형 관리자를 사용한다.
2. Clone() 연산을 구현한다.
3. Clone() 을 초기화한다.

관련 패턴
Composition, Decorator 패턴에서 Prototype패턴을 쓰는 것을 추천함

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

2016년 2월 23일 화요일

Web.xml의 개요, 기능, 활용

1. Web.xml 개요

1.1 Web.xml이란?

Web Application의 Deployment Descriptor(환경파일 : 배포서술자, DD파일)로서 XML 형식의 파일

모든 Web application은 반드시 하나의 web.xm l파일을 가져야 함

위치 : WEB-INF 폴더 아래

web.xml 파일의 설정들은 Web Application 시작시 메모리에 로딩됨. (수정을 할 경우 web application을 재시작 해야함.)

1.2 Web.xml에 작성되는 내용

ServletContext의 초기 파라미터

Session의 유효시간 설정

Servlet/JSP에 대한 정의

Servlet/JSP 매핑

Mime Type 매핑

Welcome File list

Error Pages 처리

리스너/필터 설정

보안

1.3 xml 작성시 주의점

대소문자를 구분 해줘야 한다.

attribute 값은 반드시 " " 또는 ' '으로 감싸야 한다.

태그는 반드시 닫아야 한다. ※ content가 없는 태그의 경우 → ex) <br/>

1.4 서블릿 설정

servlet-name : 아래 servlet-mapping에 기술주기 위한 식별자

servlet-class : 실제 서블릿 클래스, 패키지까지 정확하게 기술

<servlet> : 서블릿 객체 설정

<servlet-name> : 객체의 이름    </servlet-name>

<servlet-class> : 객체를 생성할 클래스    </servlet-class>

</servlet>

servlet-name : 위에 servlet에 명시한 이름
url-pattern : 어떠한 URL경로로 접근할 수 있는지를 명시

<servlet-mapping>

<servlet-name> 이름 </servlet-name> 일할 서블릿 객체의 이름

<url-pattern>패턴</url-pattern> 클라이언트가 요청할 url 패턴

</servlet-mapping>

기타요소

<!-- 세션 기간 설정 -->
    <session-config>
      <session-timeout>
        30
      </session-timeout>
    </session-config>

    <!-- mime 매핑 -->
    <mime-mapping>
      <extension>txt</extension>
      <mime-type>text/plain</mime-type>
    </mime-mapping>

    <!-- 시작페이지 설정 -->
    <welcome-file-list>
      <welcome-file>index.jsp</welcome-file>
      <welcome-file>index.html</welcome-file>
    </welcome-file-list>

    <!-- 존재하지 않는 페이지, 404에러시 처리 페이지 설정 -->
    <error-page>
      <error-code>404</error-code>
      <location>/error.jsp</location>
    </error-page>

    <!-- 태그 라이브러리 설정 -->
    <taglib>
      <taglib-uri>taglibs</taglib-uri>
      <taglib-location>/WEB-INF/taglibs-cache.tld</taglib-location>
    </taglib>

    <!-- resource 설정 -->
    <resource-ref>
      <res-ref-name>jdbc/jack1972</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
    </resource-ref>

출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26740333&

GoF의 디자인 패턴 - Factory Method

Creational Patterns(생성 패턴) :: Factory Method(팩토리 메서드)

구분
클래스 생성 (Class Creational)

의도
- 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할 지에 대한 결정은 서브클래스가 한다.

사용시기
- 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때
- 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때
- 객체 생성의 책임을 몇 개의 보조 서브클래스 가운데 하나에게 위임하고, 어떤 서브클래스가 위임자인지에 대한 정보를 국소화(localization)시키고 싶을 때

관련 패턴
Factory Method는 Abstract Factory 패턴과 Template Method 패턴에서 사용될 때가 많다.

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

GoF의 디자인 패턴 - Builder

Creational Patterns(생성 패턴) :: Builder(빌더)

구분
객체 생성 (Object Creational)

의도
- 복잡한 객체를 생성하는 방법과 표현하는 방법의 정의하는 클래스를 별도로 분리하여 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공할 수 있도록 한다.

사용시기
- 복합 객체의 생성 알고리즘이 복합 객체를 합성하는 요소 객체들과 상관없이 독립적일 때
- 합성할 객체들의 표현이 서로 다르더라도 생성 절차에서 이를 지원해야 할 때

장점과 단점
1. 제품에 대한 내부 표현을 다양화 시킬 수 있다.
2. 생성과 표현에 필요한 코드의 분리

관련 패턴
복잡한 객체의 생성에 있어서 추상 팩토리 패턴과 빌더 패턴은 비슷하다.
차이가 있다면, 빌더 패턴은 복잡한 객체의 단계별 생성에 중점을 둔 반면, 추상 팩토리 패턴은 제품의 유사군들이 존재할 때 유연한 설계에 중점을 둔다.
빌더 패턴은 생성의 마지막 단계에서 생성한 제품을 반환하는 반면, 추상 패토리 패턴은 만드는 즉시 제품을 반환한다. 제품 하나만으로도 의미가 있기 때문이다.

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

GoF의 디자인 패턴 - Abstract Factory

Creational Patterns(생성 패턴) :: Abstract Factory(추상 팩토리)

구분
객체 생성 (Object Creational)

의도
상세화된 서브클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터페이스를 제공

사용시기
- 객체가 생성되거나 구성/표현되는 방식과 무관하게 시스템을 독립적으로 만들고자 할 때
- 여러 제품군 중 하나를 선택해서 시스템을 설정해야 하고 한번 구성한 제품을 다른 것으로 대체할 수 있을 때
- 관련된 제품 객체들이 함께 사용되도록 설계되었고, 이 부분에 대한 제약이 외부에도 지켜지도록 하고 싶을 때
- 제품에 대한 클래스 라이브러리를 제공하고, 그들의 구현이 아닌 인터페이스를 노출시키고 싶을 때

장점과 단점
1. 구체적인 클래스의 분리
- 추상 팩토리 패턴을 쓰면 응용프로그램이 생성 할 객체의 클래스를 제어할 수 있다. 팩토리는 제품 객체를 생성하는 과정과 책임을 캡슐화한 것이기 때문에 구체적인 구현 클래스가 사용자로부터 분리된다. 일반 프로그램은 추상 인터페이스를 통해서만 인스턴스를 조작한다. 제품 클래스 이름이 구체 팩토리의 구현에서 분리되므로 사용자 코드에는 나타나지 않는다.

2. 제품군을 쉽게 대처할 수 있다.
- 구체 팩토리의 클래스는 응용프로그램에서 한 번만 나타나기 때문에 응용프로그램이 사용할 구체 팩토리를 변경하기 쉽다. 또한, 구체 팩토리를 변경함으로써 응용프로그램은 서로 다른 제품을 사용할 수 있게 변경된다. 추상 패고리는 필요한 모든 것을 생성하기 때문에 전체 제품군은 한번에 변경이 가능하다.

3. 제품 사이의 일관성 확보
- 하나의 군 안에 속한 제품 객체들이 함께 동작하도록 설계되어 있을 때, 응용프로그램은 한 번에 오직 한 군에서 만든 객체를 사용하도록 함으로써 프로그램의 일관성을 갖도록 할 수 있다.

4. 새로운 종류의 제품의 제공이 어려움
- 새로운 종류의 제품을 만들기 위해 기존 추상 팩토리를 확장하기가 어렵다. 생성되는 제품은 추상 팩토리가 생성할 수 있는 제품 집합에만 고정되어 있기 때문이다. 만약 새로운 종류의 제품이 등장하면 팩토리의 구현을 변경해야 한다. 이는 추상 팩토리와 모든 서브클래스의 변경을 가져온다. 즉, 인터페이스가 변경되는 새로운 제품을 생성하는 연산이 추가되거나, 기존 연산의 반환 객체 타입이 변경되므로 이를 상속받는 서브클래스 모두가 변경되어야 한다.

구현의 유의점
1. 팩토리를 단일체로 정의한다.
2. 제품을 생성한다.
3. 확장 가능한 팩토리들을 정의한다.

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

2016년 2월 18일 목요일

디자인패턴...유연성 편

디자인 패턴이 소프트웨어 구축에 줄 수 있는 유연성의 예

1. 특정 클래스에서 객체 생성
: 객체를 생성할 때 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속된다. 이런 종속은 앞으로의 변화를 수용하지 못한다. 이를 방지하려면 객체를 직접 생성해서는 안된다.

: 사용할 수 있는 디자인 패턴
- Abstract Factory
- Factory Method
- Prototype

2. 특정 연산에 대한 의존성
: 특정한 연산을 사용하면, 요청을 만족하는 한 가지 방법에만 매이게 된다. 요청의 처리 방법을 직접 코딩하는 방식을 피하면 컴파일 시점과 런타임 시점, 모두를 만족하면서 요청 처리 방법을 쉽게 변경할 수 있다.

: 사용할 수 있는 디자인 패턴
- Chain of Responsibility
- Command

3. 하드웨어와 소프트웨어 플랫폼에 대한 의존성
: Legacy시스템의 인터페이스는 플랫폼마다 다르다. 특정 플랫폼에 종속된 코드는 마이그레이션이 어렵다. 이러한 종속성을 제거하는 것이 중요하다.

: 사용할 수 있는 디자인 패턴
- Abstract Factory
- Bridge

4. 객체의 표현이나 구현에 대한 의존성
: A객체가 B객체의 표현 방법, 저장 방법, 구현 방법, 존재의 위치에 대한 모든 방법을 알고 있다면 B객체를 변경할 때 A객체도 함께 변경해야 한다. 이런 정보를 감춤으로써 변화의 파급을 막을 수 있다.

: 사용할 수 있는 디자인 패턴
- Abstract Factory
- Bridge
- Memento
- Proxy

5. 알고리즘 의존성
: 알고리즘에 종속된 객체가 있다면 변화에도 종속되게 되므로, 변경 가능한 알고리즘은 분리해야 한다.

: 사용할 수 있는 디자인 패턴
- Builder
- Iterator
- Strategy
- Template Method
- Visitor

6. 높은 결합도 (https://ko.wikipedia.org/wiki/%EA%B2%B0%ED%95%A9%EB%8F%84)
: 높은 결합도를 갖는 클래스는 독립적으로 재사용하기 어렵다. 또한 하나의 커다란 시스템이 되어 버린다. 결국 전체를 이해하지 못하면 조그만 변경도 하기 어려워지며, 변경 시 종속된 다른 클래스들도 함께 변경되어야 한다. (유지보수 불가의 공룡 시스템)

약한 결합도는 클래스를 재사용 가능하게 하고, 시스템의 이해와 수정, 확장이 쉬워진다. 추상 클래스 수준에서 결합도를 정의한다거나 계층화시키는 방법으로 낮은 결합도의 시스템을 만드는 것이 중요하다.

: 사용할 수 있는 디자인 패턴
- Abstract Factory
- Bridge
- Chain of Responsibility
- Command
- Facade
- Mediator
- Observer

7. 서브클래싱을 통한 기능 확장
: 서브클래싱으로 객체를 재정의하는 것은 쉬운 일이 아니다. 새로운 클래스마다 매번 반드시 해야 하는 초기화, 소멸 등에 대한 구현 오버헤드가 있기 때문이다. 서브클래스를 정의하려면, 최상위 클래스부터 자신의 직속 부모 클래스까지 모든 것을 이해하고 있어야 한다. 또한, 단순히 확장만을 이유로 새로운 서브클래스를 만든다면 서브클래싱은 클래스의 수를 엄청나게 증가시킬 수도 있다. 일반적으로 객체 합성과 위임은 상속보다 훨씬 유연한 방법이다. 기존 객체들을 새로운 방식으로 조합함으로써 새로운 서브클래스를 정의하지 않고도 새로운 기능을 추가할 수 있다. 하지만 객체 합성을 많이 사용한 시스템은 이해하기가 어려워진다. 많은 디자인 패턴에서는 그냥 서브클래스를 정의하고 다른 인스턴스와 새로 정의한 클래스의 인스턴스를 합성해서 기능을 재성의하는 방법을 도입한다.

: 사용할 수 있는 디자인 패턴
- Bridge
- Chain of Responsibility
- Decorator
- Strategy

8. 클래스 변경이 쉽지 않은 경우
: 변경을 할 경우 종속된 서브클래스들을 모두 수정해야 하는 경우 클래스를 수정하는 방법을 디자인 패턴이 제시한다.

: 사용할 수 있는 디자인 패턴
- Adapter
- Decorator
- Visitor

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

디자인패턴...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는 정말 방대하다.

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

2016년 2월 15일 월요일

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의 디자인패턴