Design Pattern

전 페이지 : ComputerForStudy

Design Pattern

강의

  • LG CNS 강의 : 객체지향 전문가들의 설계 노하우, 디자인 패턴. 2014.05.20 ~ 2014.05.22
    - 강사 : 통합모델링팀 황정연 C

Link


고민

  • 단납기, only SI, 작은 예산
    - 고품질의 설계 : 비용증가, SM시 학습필요
    - 통합테스트 : 빈번한 고객요구사항 변경, 많은 수정비용 발생
    - 통합테스트에서 더 큰 비용을 아낄 수 있다고 판단되는 부분에 적용 필요
    - SM까지 진행한다고 하면 더 넓은 범위로 적용필요

목적

  • 유연한 설계
  • 객체지향적인 설계

공통적인 설명

용어

  • 의존관계의 역전법칙

객체지향

  • 추상화(Abstraction) : 중요한 부분만 정확히 표현하고 중요하지 않은 부분은 생략하는 기술
    - 설계물로 프로젝트 초기에 의사소통을 가능하게도 해줌.

  • 다형성(Polymorphism)
    - 상속(Inheritance)
    - 구체화(Implement)

  • 캡슐화(Encapsulation)

  • 다중상속의 불가능

UML

  • class, class 관계, class diagram

  • 관계(Relation)
    - 연관(Association) : 다른 class를 field로 선언
    - 의존(Dependancy) : 다른 class를 지역변수와 같이 잠깐 사용
    - 상속(Generalization)
    - 구현(Realization)
    - 메소드재정의(Overriding)
    - Multiplicity : 다른 class를 참조하는 개수

Principles for the Good Design

  • KISS : Keep It Simple Status
  • DRY : Don't Repeat Yourself
  • YAGNI : You Are not Going to Need It.
  • GRASP : General Responsibility Assignment Software Patterns
  • SOLID
    - Single Responsibility Principle : 책임을 분리의 기준으로 잡고 하나의 책임을 갖도록 분리시켜라
    - Open-Closed Principle : 확장에대해서는 개방, 변경에대해서는 폐쇄. 확장성 좋아야하지만 변경시 영향도가 적어야한다.
    - Liskov Substitutiion Principle : 서브타입은 언제나 자신이 기반타입으로 교체할 수 있어야한다.
    - Interface Segregation Principle : 일반적인 단일 인터페이스보다는 구체적인 다수의 인터페이스가 낫다. 성격이 다른 interface를 분리하라.
    - Dependency Inversion Principle : 추상화 된 것이 구체적인 것에 의존하면 안된다.

  • 나쁜설계
    - 경직성
    - 부서지기 쉬움
    - 부동성

패턴사용에 관한 충고

  • 배워라
  • 언제 적용해야 할지 판단해라
  • 너무 복잡하면 버려라

Strategy Pattern


  • 변화에 무관한 부분과 변화에 민감한 부분을 나눠서 설계한다.
    - 변화에 무관한 부분 : 변화에 무관한 공통부분을 context에서 제공하고 변화에 민감한 부분을 사용한다.
    - 변화에 민감한 부분 : interface & 구현체
    - 변화에 민감한 부분은 구현체를 늘려감에 따라 확장가능.
    - 구현체를 선택함으로써 해당 기능을 사용가능.

  • 전략패턴은 정적인 설계에 적합.
  • 전략을 동적으로 사용하기 위해서는 Factory Method Pattern이 필요.

  • 단점 ( 바뀌는 빈도수와 같은 비용을 고려할 필요있음 )
    - 클라이언트가 각 전략 객체들을 알고 있어야함.
    - 객체 수 증가
    - 커뮤니케이션 오버헤드 발생

http://amrelroumy.github.io/2011/07/strategy_pattern3.png
http://i.stack.imgur.com/EIsOf.png

Adapter Pattern

  • 우리가 사용할 수 없는 자원을 사용할 수 있도록 해주는 패턴
  • class adapter : 상속을 통해서 처리
  • object adapter : 객체를 생성 및 사용해서 처리

http://i.msdn.microsoft.com/dynimg/IC400935.png

Template Method Pattern

  • 제어가 역전되는 구조
  • 코드 재사용을 위해 사용하는 기본적인 기법 중 하나
  • 전체 프로세스의 로직은 super가 가지고 세부적인 기능들은 sub에서 override 해서 구현
  • 단점 : sub는 super의 로직을 알수가 없다.
  • 장점 : sub는 super의 로직을 알 필요가 없다.
  • super의 전체 프로세스 로직 메소드는 final로 선언해서 sub에서 override 못하도록한다.

http://sourcemaking.com/files/sm/images/11fig13.gif

Factory Method Pattern

  • 의존관계를 갖는 객체생성을 전담으로하는 처리 메소드
  • 의존성 객체를 한곳에서 관리할 수 있다.
  • 전략패턴과 함께 쓰인다.
  • Factory도 Creator 와 ?ConcreteCreator로 나눠서 설계 가능하다.
  • 장점
    - 객체 생성 방식을 클라이언트로부터 빼내서 복잡도를 낮추고, 생성방식이 바뀌어도 기존코드가 변하지 않는다.
    - 객체 생성에 대해서 한눈에 볼 수 있다.

http://sourcemaking.com/files/sm/images/patterns/Factory_Method__.gif

Decorator Pattern

  • 정적인 상속보다 좀 더 유연하게 확장할 수 있다.
  • 다양한 조합이 가능하다.

http://cnx.org/content/m26102/latest/decorator.jpg

Singleton Pattern


Proxy Pattern

  • 특정 객체에 대한 대리 객체를 만들어서 접근을 제한한다.
    - 대상객체를 사용하기 어려운 상황 : 비싼자원, 네트웍연결, 메모리문제, 디스크 액세스
    - 중요한 일을 하는 객체를 보호하기 위해 : 권한체크, 접근에 대한 제
  • 프록시를 통해서만 접근하도록 근본 리소스를 제한필요

http://www.dofactory.com/Patterns/Diagrams/proxy.gif

Facade Pattern

  • 간단한 인터페이스를 제공하고 내부적으로 복잡한 로직을 처리한다.
  • 외부에서 접근이 편해진다.
  • 외부에서 내부 로직에 접근하지 못하도록 해야한다.
http://www.thecoldsun.com/sites/default/files/images/Facade%20Pattern.png

Observer Pattern

  • 출판자, 구독자 사이의 강한 커플링을 단방향으로 만들어준다.
  • Observerable 객체가 있지만 대부분 사용못한다. 다중상속 문제 때문에.

http://www.bogotobogo.com/DesignPatterns/images/observer/observer_pattern.gif

Command Pattern


http://javaobsession.files.wordpress.com/2010/07/command-pattern.png