디자인 패턴(Design pattern) - 정의 및 분류

Design patterns aren't the designs people tend to generate initially. They reflect untold redesign and receding as developers have struggled for greater reuse and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form.

디자인 패턴은 처음부터 작성되는 코드가 아닙니다. 코드들 개발자가 소프트웨어에서 더 큰 재사용과 유연성을 위해 고군분투함에 따라, 계속된 재설계와 후퇴의 과정이 반영 됩니다. 디자인 패턴은 이러한 고군분투가 담겨있는 재사용과, 유연성을 위한 솔루션을 간결하고 쉽게 적용할 수 있는 형태로 되어있습니다.

 

All can be implemented in standard object-oriented languages, though they might take a little more work than ad hoc solutions. But the extra effort invariably pays dividends in increased flexibility and reusability.

모두 표준 객체 지향 언어로 구현할 수 있지만 임시 솔루션보다 작업이 조금 더 필요할 수 있습니다. 그러나 추가 노력은 항상 유연성과 재사용성을 증가시키는 이점을 제공합니다.

Once you understand the design patterns, you'll have insights that can make your own designs more flexible, modular, reusable, and understandable.

다지인 패턴을 이해하게되면, 자신의 설계을 보다 유연하고, 규격을 갖추며, 재사용 가능하고, 이해하기 쉽게 만들 수 있는 통찰력을 갖게 됩니다.

 

 

학습 방법

1. 패턴간의 논리적 연관성 분석 (logical relation between the patterns)

You can study how closely related patterns distinguish themselves. You can use the references between the patterns as a logical route through the catalog. This approach will give you insight into how patterns relate to each other, how they can be combined with other patterns, and which patterns work well together.

서로 밀접하게 관련된 패턴이 어떻게 구별되는지 학습할 수 있습니다. 패턴을 하나씩 공부하면서 다른 패턴이 서로 어떻게 관련되는지, 패턴이 다른 패턴과 결합될 수 있는지, 어떤 패턴이 함께 잘 작동하는지에 대한 통찰력을 제공합니다.

 

2. 문제 지향적 접근법 (problem-directed approach)

Yet another way is to use a more problem-directed approach. 
First, read about some common problems hi designing reusable object-oriented software; then read the patterns that address these problems.

또 다른 방법은 보다 문제 지향적인 접근 방식을 사용하는 것입니다. 먼저, 재사용 가능한 객체 지향 소프트웨어를 설계할 때 발생하는 몇 가지 일반적인 문제에 대해 읽으십시오. 그런 다음 이러한 문제를 해결하는 패턴을 읽으십시오.

 

 

some common causes of redesign & the design patterns that address them

재설계의 몇 가지 일반적인 원인 & 이를 해결하는 디자인 패턴

---

1. 디자인 패턴이란

 

4가지 디자인패턴의 필수요소

1. 패턴 이름

2. 문제점

3. 해결책

4. 결과

Describing Design Patterns (디자인 패턴 설명하기)

 

 

 

---

2. 23개 디자인 패턴들의 종류와 분류

 

 

두 가지 기준에 따라 디자인 패턴를 분류합니다(표 1. 1).

목적이라고 하는 첫 번째 기준은 패턴이 하는 일을 반영합니다. 패턴은 생성 목적, 구조적 목적 또는 행동 목적을 가질 수 있습니다.

생성 패턴은 객체 생성 프로세스와 관련이 있습니다.

구조적 패턴은 클래스나 객체의 구성을 다룬다.

행동 패턴은 클래스나 객체가 상호 작용하고 책임을 분배하는 방식을 특징짓습니다.

 

디자인패턴의

1. 이름 : 문제,해결,결과를 포괄하는 단어

2. 문제 : 패턴을 언제 적용해야하는지. 특정 설계나 구조의 문제점 설명

3. 해결책 : 패턴은 설계 문제에 대한 추상적인 설명과 요소(클래스 및 객체)의 일반 배치가 이를 해결하는 방법을 제공

5. 결과 : 패턴 적용 비용과 이점(재사용성- 시스템의 유연성, 확장성 또는 이식성)

 

객체 지향 프로그램은 객체로 구성됩니다.
object (객체)는 데이터와 해당 data(데이터)에서 작동하는 procedures(프로시저, 절차)로 구성되어있습니다.,
프로시저(절차)는 일반적으로 methods or operations(메서드 또는 작업)이라고 합니다.

객체는 클라이언트로부터 요청(또는 메시지)을 받을 때 작업을 수행합니다.

purpose

 

scope

 

 

생성

1. Abstract Factory :
   • Provide an interface for creating families of related or dependent objects without specifying their concrete classes. (구체적인 클래스를 지정하지 않고, 관련 또는 종속 객체의 패밀리를 생성하기 위한 인터페이스를 제공합니다.)
2. Builder :
   • Separate the construction of a complex object from its representation so that the same construction process can create different representations. (복잡한 객체의 구성을 해당 표현과 분리하여 동일한 구성 프로세스에서 다른 표현을 생성할 수 있습니다.)
3. Factory Method :
   • Define an interfa ce for creating an object, but let subcl asses decide which class to instantiate. Factory Method lets a cl ass defer instantiation to subclasses. (객체 생성을 위한 인터페이스를 정의하지만, 서브클래스가 인스턴스화할 클래스를 결정하도록 합니다. 팩토리 메소드를 사용하면 클래스가 인스턴스화를 서브클래스로 연기할 수 있습니다.)
4. Prototype :
   • Specify the kinds of obj ectsto crea te using a prototypi cal instance, and create new obj ectsby copying this prototype. (프로토타입 인스턴스를 사용하여 생성할 객체의 종류를 지정하고 이 프로토타입을 복사하여 새로운 객체를 생성합니다.)
5. Singleton :
   • Ensure a class only has one instance, and provide a global point of access to it.  (클래스에 인스턴스가 하나만 있는지 확인하고 이에 대한 전역 액세스 지점을 제공합니다.)

 

---

 

구조

1. Adapter :
   • Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompat ibleinterfaces. (클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환합니다. 어댑터를 사용하면 호환되지 않는 인터페이스로 인해 다른 방법으로는 할 수 없었던 클래스가 함께 작동할 수 있습니다.)
2. Bridge :
   • Decouple an abstraction from its implementation so that the two c an vary independently. (두 가지가 독립적으로 변할 수 있도록 구현에서 추상화를 분리합니다.)
3. Composite :
   • Compose obje cts into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. (객체를 트리 구조로 구성하여 부분-전체 계층 구조를 나타냅니다. 복합을 사용하면 클라이언트가 개별 개체와 개체 구성을 균일하게 처리할 수 있습니다.)
4. Decorator :
   • Att achadditional responsibilitie s to an obj ectdynamically. Decorators provide a flexible alternative to subclassing for extending functionality. (대상에 대한 추가적 책임을 동적으로 수행합니다. 데코레이터는 기능 확장을 위해 서브클래싱에 대한 유연한 대안을 제공합니다.)
5. Facade :
   • Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interf acethat makes the subsystem easier to use. (하위 시스템의 인터페이스 집합에 통합 인터페이스를 제공합니다. Facade는 하위 시스템을 더 쉽게 사용할 수 있도록 하는 상위 수준 인터페이스를 정의합니다.)
6. Flyweight :
   • Use sharing to support large numbers of fine-grained objects efficiently. (공유를 사용하여 많은 수의 세분화된 개체를 효율적으로 지원합니다.)
7. Proxy :
   •  Provide a surrogate or placeholder for another object to control access to it.  (다른 개체에 대한 액세스를 제어하기 위해 대리 또는 자리 표시자를 제공합니다.)

 

---

행동

1. Chain of Responsibility :
   • Avo id coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an obje ct handles it. (요청을 처리할 기회를 두 개 이상의 객체에 제공하여 요청의 발신자와 수신자를 연결하는 것을 방지합니다. 수신 개체를 연결하고 개체가 처리할 때까지 연결을 따라 요청을 전달합니다.)
2. Command :
   • Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. (요청을 개체로 캡슐화하여 다른 요청으로 클라이언트를 매개변수화하고 요청을 대기열에 넣거나 기록하고 실행 취소할 수 있는 작업을 지원할 수 있습니다.)
3. Interpreter :
   • Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sent ences in the language.  (언어가 주어지면 해당 언어의 문장을 해석하기 위해 표현을 사용하는 인터프리터와 함께 문법에 대한 표현을 정의합니다.)
4. Iterator :
   • Provide a way to access the elements of an aggregate object sequentially without exposi ng its underlying representation. (기본 표현을 노출하지 않고 집계 개체의 요소에 순차적으로 액세스하는 방법을 제공합니다.)
5. Mediator :
   • Define an object that encapsulates how a set of objects interact. Mediator promotes l oose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. (개체 집합이 상호 작용하는 방식을 캡슐화하는 개체를 정의합니다. Mediator는 개체가 서로를 명시적으로 참조하지 않도록 하여 느슨한 결합을 촉진하고 개체의 상호 작용을 독립적으로 변경할 수 있도록 합니다.)
6. Memento :
   • Without violating encapsulation, capture and externalize an object's internal state so that the object ca n be restored to this state later.  (캡슐화를 위반하지 않고 객체의 내부 상태를 캡처하고 외부화하여 객체가 나중에 이 상태로 복원될 수 있도록 합니다.)
7. Observer :
   • Define a one-to-any dependency between objects so that when one object changes state, all its dependents are notified and upda tedautomatically. (한 개체의 상태가 변경되면 모든 종속 항목에 자동으로 알림 및 업데이트되도록 개체 간의 일대일 종속성을 정의합니다.)
8. State :
   • Allow an object to alter its behavior when its internal state changes. The object will appear to change its cl ass.  (객체의 내부 상태가 변경될 때 객체가 동작을 변경할 수 있도록 합니다. 개체가 클래스를 변경하는 것처럼 보입니다.)
9. Strategy :
   • Define a family of algorithms, encapsulate each one, and make them interchangeable. Strate gylets the algorithm vary independently from clie nts that use it. (알고리즘 제품군을 정의하고 각각을 캡슐화하고 상호 교환 가능하게 만드십시오. Strate gylets 알고리즘은 이를 사용하는 클라이언트와 독립적으로 다릅니다.)
10. Template Method :
    • Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Temp lateMethod lets subclasses redefine certain steps of an algorithm without changing the algorithm 's structure. (작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. TemplateMethod를 사용하면 알고리즘의 구조를 변경하지 않고도 하위 클래스가 알고리즘의 특정 단계를 재정의할 수 있습니다.)
11. Visitor :
    • Represent an operation to be performed on the elements of an object structure. Viitor lets you define a new operation without changing the classes of the elements on which it operates. (개체 구조의 요소에 대해 수행할 작업을 나타냅니다. 방문자를 사용하면 작업하는 요소의 클래스를 변경하지 않고 새 작업을 정의할 수 있습니다.)

 

 

참고서적 GoF의 디자인 패턴