디자인 패턴(구)

디자인 패턴의 종류

공대키메라 2022. 3. 28. 11:42

필자는 디자인 패턴에 대해 관심을 가지려고 하는데

 

어떤 방식으로 디자인 패턴을 구분하고 어떤 종류가 있는지 잘 몰랐다.

 

그래서 인터넷에서 이에 대한 정보를 추합해 정리하고자 한다. 

 

출처 : https://www.geeksforgeeks.org/design-patterns-set-1-introduction/

출처 : https://sourcemaking.com/design_patterns

1. What is Design Pattern

디자인 패턴은 소프트웨어 디자인에서 발생하는 공통 문제에 일반적이고 재사용 가능한 해결책을 제시한다!
패턴은 전형적으로 클래스와 객체 사이의 관계와 상호작용을 보여준다.

이 아이디어는 잘 검사되고 입증된 개발 패러다임을 제공함으로 개발 프로세스를 빠르게 한다. 디자인 패턴은 공통의 문제를 해결하기위한 프로그래밍 언어에 독립적인 전략들이다.

이것은 디자인 패턴이 아이어를 나타내는 것이지 특정한 구현을 말하는게 아니라는 것이다. 디자인 패턴을 사용하면, 당신의 코드는 더 유연하고 재사용 가능하고, 유지할 수 있을 것이다!

 

=> 디자인 패턴 정말 좋네... 무언가 제대로 개발을 하고 싶다면 이러한 방법론을 알아야 생산성이 증대가 될 것 같다. 

 

항상 프로젝트에 디자인 패턴을 적용하는게 의무인건 아니다.
디자인 패턴은 프로젝트 개발을 위한게 아니다.

디자인 패턴은 공통 문제 해결을 위한 것이다. 필요할 때 마다, 미래의 그러한 문제를 피하기 위해 잘 맞는 패턴을 구현해야만 한다. 어떤 패턴을 사용할지 알기위해, 디자인 패턴을 이해하고 그들의 목적을 알아야만 한다. 그렇게 함으로서, 옳은 방법을 고를 수 있을 것이다. 

 

=> 디자인 패턴은 결국 필수적인것은 아니지만 미래에 맞닥드릴 문제에 대한 해결책을 미리 제공할 수 있고, 그러기 위해 어떤 디자인 패턴이 적합한지 미리 알아야 한다. 

 

그러면 어떤 디자인 패턴이 있는지 알아보겠다. 

 

디자인 패턴은 주로 3개의 타입으로 나뉜다.

 

  • Creational(생성) 
  • Structural(구조)
  • Begavioral(행위) 

 

2. Creational Design Pattern 

이 디자인 패턴들은 클래스 인스턴스화 혹은 객체 생성에 대한 것이다.
즉, 객체의 생성에 관련된 패턴으로 객체의 생성절차를 추상화하는 패턴이다.

이 패턴은 클래스 생성 패턴과 객체 생성 패턴으로 더 나뉠 수 있다. 클래스 생성 패턴이 인스턴스화 과정에서 효과정으로 상속을 사용할 수 있는 반면, 객체 생성 패턴은 일이 행해지도록 효과적으로 위임을 사용한다. 

생성 디자인 패턴에는 팩토리 메서드, 추상 팩토리, 빌더, 싱글톤, 객체 풀, 프로토타입이 있다. 

 

  • Abstract Factory
    Creates an instance of several families of classes
  • Builder
    Separates object construction from its representation
  • Factory Method
    Creates an instance of several derived classes
  • Object Pool
    Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
  • Prototype
    A fully initialized instance to be copied or cloned
  • Singleton
    A class of which only a single instance can exist

 

그리고 언제 사용하는지에 대한 설명이 다음에 온다. 

 

use case of creational design pattern

상황 1

간단한 DBConnection 클래스를 만들고 다양한 장소에서 DB에 접근하고 싶을 때 개발자는 필요할 때 마다 DBConnection Class를 인스턴스화 할 것이다. 그렇게 되면 접을 할 때 마다 다양한 connections들을 만들게 되는데 이것을 다루기 위해 Singleton class로 보통 클래스를 생성해서 사용한다. 우리는 하나의 인스턴스를 통해 DB Connection을 관리할 수 있기 때문에, load balance와 불필요한 연결을 제어할 수 있다.

 

상황 2

다양한 비슷한 종류의 인스턴스를 생성하고 결합성을 낮추길 원한다고 가정한다면, 팩토리 패턴이 좋을것이다. 팩토리 디자인 패턴을 구현하는 클래스는 다양한 클래스들 사이에 다리 역할을 한다. SQL Server나 Oracle같은 다양한 데이터 베이스를 사용한다 해보자. back end로서 SQL Server Database 를 사용하는 애플리케이션을 개발한는데 미래에 oracle을 사용해야 한다면, 모든 코드를 수정해야될 수도 있다. 그래서 팩토리 디자인 패턴은 결합도를 낮추고, 구현을 쉽게 해기에 우리는 비슷한 종류의 객체를 생성하고 느슨한 결합을 이루기 위해 팩토리 디자인 패턴을 사용할 수 있다. 

 

공통적으로 읽어보면 불필요한 중복도 제거하고, 느슨한 결합을 가능하게 하고, 결국 이것이 후에 수정이 일어났을 시에도 대처하기 쉽도록 한다는 것이 생성 디자인 패턴의 장점이다. 

 

3. Strucural Design Pattern

이 디자인 패턴은 더 큰 구조를 제공하고, 새로운 기능을 제공하기 위해 다른 클래스와 객체를 조직화하는 것이다. 

구조 디자인 패턴에는 어댑터, 브릿지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프라이빗 클래스 데이터, 프록시가 있다. 

 

  • Adapter
    Match interfaces of different classes
  • Bridge
    Separates an object’s interface from its implementation
  • Composite
    A tree structure of simple and composite objects
  • Decorator
    Add responsibilities to objects dynamically
  • Facade
    A single class that represents an entire subsystem
  • Flyweight
    A fine-grained instance used for efficient sharing
  • Private Class Data
    Restricts accessor/mutator access
  • Proxy
    An object representing another object

use case of Structural design pattern

상황 1

두개의 인터페이스가 서로 호환되지 않고 어탭터를 통해 둘 사리의 관계를 만들고 싶다면 그것이 adapter 패턴이라고 불린다. (무언가 국가마다 다른 전력을 변환해주는 변환기와 비슷한 느낌이 든다. 관계가 없지만 변환을 통해 서로 상호작용이 가능하게 하는것이!) 어탭터 패턴은 클라이언트가 예상하는 다른 인터페이스 혹안 클래스를 한 클래스의 인터페이스로 변환한다. 즉, 어댑터는 클래스들이 비호환성 때문에 그렇지 못한 클래스들을 함께 작동하도록 해준다. 고로 비호환성의 경우에는, 어탭터 패턴을 사용할 수 있다. 

 

4. Behavioral Design Pattern

행위 패턴은 객체들 사이의 공통 커뮤니케이션 패션들을 식별하고 이러한 패턴들을 이해하는 것이다. 

행위 패턴에는 책임 연쇄, 명령, 인터프리터, 이터레이터, 중재자, 모멘토, 널 오브젝트, 옵저버, 상태, 전략, 템플릿 메서드, 방문자 패턴들이 있다. 

 

  • Chain of responsibility
    A way of passing a request between a chain of objects
  • Command
    Encapsulate a command request as an object
  • Interpreter
    A way to include language elements in a program
  • Iterator
    Sequentially access the elements of a collection
  • Mediator
    Defines simplified communication between classes
  • Memento
    Capture and restore an object's internal state
  • Null Object
    Designed to act as a default value of an object
  • Observer
    A way of notifying change to a number of classes
  •  State
    Alter an object's behavior when its state changes
  • Strategy
    Encapsulates an algorithm inside a class
  • Template method
    Defer the exact steps of an algorithm to a subclass
  • Visitor
    Defines a new operation to a class without change

 

Use Case of Behavioral Design Pattern

 

상황 1

템플릿 패턴은 하위 클래스에 몇가지 단계를 다르게 하는 작업에서 알고리즘의 뼈대를 정의한다. 템플릿 메서드는 서브클래스들이 알고리즘의 구조를 변경하는것 없이 특정한 단계들을 재정의하도록 한다. 예를 들어, 프로젝트에서 우리가 새로운 모듈을 어플리케이션의 변화의 요구로, 혹은 새로운 어플리케이션의 요구를 충족시키기 위해 다른 방법과 방식으로 행동하도록 만들기 위해서 확장할 수 있는 모듈의 행위를 원한다. 하지만 아무도 소드 코드를 바꾸도록 할 수 는 없다. 즉, 추가는 할 수 있지만 개발자가 템플릿 디자인 패턴에 접근할 수 있는 구조를 수정할 수 는 없다. 

 

=> 이게 무슨 말이냐면... 팀플릿 패턴으로 알고리즘의 뼈대를 만들었지만, 그 뼈대 위에서 우리가 작업을 추가할 수는 있지만 알고리즘의 뼈대 자체를 수정할 수는 없다는 것 같다. 

 


오늘은 대략적으로 어떤 디자인 패턴들이 있는지, 그리고 어떤 특징을 가지고 있는지 알아봤다. 

 

앞으로 시간이 날 때마다 디자인 패턴을 구현해보고 이것이 이렇구나 하는 개념을 잡아갈 것이다.

'디자인 패턴(구)' 카테고리의 다른 글

객체 지향 5대 원칙  (0) 2022.03.29