Skip to content

JeongInjin/newGofDesignPattern

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

28 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

#헤드퍼스트 디자인패턴 개정판

  • 디자인 패턴 원칙

    1. 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분과 분리한다.
    2. 구현보다는 인터페이스에 맞춰서 프로그래밍한다.
    3. 상속보다는 구성을 활용한다.
    4. 상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다.
    5. 클래스는 확장에는 열려있어야 하지만 변경에는 닫혀 있어야 한다.(Open-Closed Principle)
    6. 추상화된 것에 의존하게 만들고 구상 클래스에 의존하지 않게 만든다.(의존성 뒤집기 원칙 - Dependency Inversion Principle)
    7. 진짜 절친에게만 이야기해야 한다
      1. 최소 지식 원칙(Principle of Least Knowledge)에 따르면 객체 사이의 상호작용은 될 수 있으면 아주 가까운 '친구' 사이에서만 허용하는 편이 좋습니다.
    8. 할리우드 원칙: 먼저 연락하지마세요. 저희가 연락 드리겠습니다.
    9. 어떤 클래스가 바뀌는 이유는 하나뿐이어야 한다.
  • 디자인 패턴을 얘기할 때, "인터페이스를 구현한다" 라는 표현이 나온다고 해서 항상 "클래스를 선언하는 부분에 implements 를 써서 구현하는 클래스를 만든다" 라고 생각하면 안됩니다. 일반적으로 어떤 상위 형식(클래스와 인터페이스)에있는 구상 클래스는 그 상위 형식의 '인터페이스를 구현하는' 클래스라고 생각하면 됩니다.


  • 전략 패턴(Strategy pattern)
    • 알고리즘을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해줍니다.
    • 전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있습니다.

  • 옵저버 패턴(Observer pattern)
    • 신문사 + 구독자 = 옵저버 패턴
    • 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의합니다.

  • 데코레이터 패턴(Decorator pattern)
    • 객체의 추가 요소를 동적으로 더할 수 있습니다.

    • 데코레이터를 사용하면 서브클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있습니다.

    • 특징

      • 자신이 자익하고 있는 객체에게 어떤 행동을 위임하는 일 말고도 추가 작업을 수행할 수 있습니다.
    • 단점

      • 잡다한 클래스가 너무 많아 진다.

  • 팩토리 메소드 패턴(Factory Method pattern)

    • 간단한 팩토리는 디자인 패턴이라기 보다는 프로그래밍에 자주 쓰이는 관용구 에 가깝다.
    • 정의
      • 객체를 생성할 때 필요한 인터페이스를 만듭니다.
      • 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정합니다.
      • 팩토리 메소드 패턴을 사용하면 클래스 인스턴스 만드는 일을 서브클래에게 맡기게 됩니다.
  • 추상 팩토리 패턴(Abstract Factory Pattern)

    • 구상 클래스에 의존하지 않고도 서로 연관되거나 의존적인 객체로 이루어진 제품군을 생산하는 인터페이스를 제공합니다.
    • 구상 클래스는 서브클래스에서 만듭니다.

  • 싱글톤 패턴(Singleton Pattern)
    • 클래스 인스턴스를 하나만 만들고, 그 인스터스로의 전역 접근을 제공합니다.

  • 커맨드 패턴(Command Pattern)
    • 요청 내역을 객체로 캡슐화해서 객체를 서로 다른 요청 내역에 따라 매개변수화할 수 있습니다.
    • 이러면 요청을 큐에 저장하거나 로그로 기록하거나 작업 취소 기능을 사용할 수 있습니다.

  • 어댑터 패턴(Adapter Pattern)
    • 특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환합니다.
    • 인터페이스가 호환되지 않아 같이 쓸 수 없었던 클래스를 사용할 수 있게 도와줍니다.

  • 파사드 패턴(Facade Pattern)
    • 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어 줍니다.
    • 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있습니다.

  • 템플릿 메소드 패턴(Template Method Pattern)
    • 알고리즘의 골격을 정의합니다.
    • 템플릿 메소드를 사용하면 알고리즘의 일부 단계를 서브클래스에서 구현할 수 있으며,
    • 알고리즘의 구조는 그대로 유지하면서 알고리즘의 특정 단계를 서브클래스에서 재정의할 수도 있습니다.

  • 반복자 패턴(Iterator Pattern)
    • 컬렉션의 구현 방법을 노출하지 않으면서 집합체 내의 모든 항목에 접근하는 방법을 제공합니다.

  • 컴포지트 패턴(Composite Pattern)
    • 객체를 트리구조로 구성해서 부분-전체 계층구조를 구현합니다.
    • 컴포지트 패턴을 사용하면 클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있습니다.

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

  • 프록시 패턴(Proxy Pattern)
    • 특정 객체로의 접근을 제어하는 대리인을 제공합니다.

About

헤드퍼스트 디자인패턴 개정판!!두둥!!

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages