객체지향과 디자인 패턴

객체지향 프로그래밍이란

 

프로그램의 동작을 객체 단위로 나눠서 수행할 수 있도록 하는 것이 객체지향 프로그래밍이다.

 

객체지향 프로그래밍을 어떻게 하면 객체 단위로 잘 나누고 연관 지을 수 있는가? 에 대한 5가지 원칙이 있습니다.

 

객체지향 설계를 하는 5가지 원칙(SOLID)

1.  SRP(Single responsibility principle) / 단일 책임 원칙
   • 하나의 클래스(객체)는 하나의 책임만 가져야한다. 
2.  OCP(Open / closed principle) / 개방-폐쇄 원칙 
   • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
3.  LSP(Liskov substitution principle) / 리스코프 치환 원칙
   • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다.
   • 추상객체로 사용되는 부분에 구상객체가 들어가도 아무 문제가 없어야 한다.
4.  ISP(Interface segregation principle) / 인터페이스 분리 원칙
   • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
5.  DIP(Dependency inversion principle) / 의존관계 역전 원칙
   • 프로그래머는 "추상화에 의존해야한다. 구체화에 의존하면 안된다."

 

- 원칙에 따라 설계를 해보았을 때 여러가지 경우에서 공통점이 보였고, 공통점들을 모아놨습니다.

=> 그것이 "디자인패턴"책이라고 합니다.

 

23가지 디자인 패턴의 종류와 의미

디자인 패턴은 GoF 라는 사람들에 의해서 쓰여진 책으로 23가지의 디자인 패턴을 정리하고 각각의 디자인 패턴을 크게 3가지로 분류했다.

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

 

1. 생성 패턴

1. Abstract Factory
   • 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공한다.
2. Builder
   • 복합 객체의 생성 과정과 표현 방법을 분리함으로써 동일한 생성 공정이 서로 다른 표현을 만들 수 있게 한다.
3. Factory Method
   • 객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만들 클래스의 결정은 서브클래스가 한다.
   • Factory Method 패턴에서는 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룬다.
4. Prototype
   • 프로토타입의 인스턴스를 이용해서 생성할 객체의 종류를 명세하고 이 프로토타입을 복사해서 새로운 객체를 생성한다.
5. Singleton
   • 클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할 수 있는 방법을 제공한다.

2. 구조 패턴

1. Adapter
   • 어댑터는 호환되지 않는 인터페이스를 가진 객체가 협업할 수 있는 구조 설계 패턴입니다.
2. Bridge
   • 추상화와 구현을 분리하여 각각을 독립적으로 변형할 수 있게 한다. 구현과 추상화 개념을 분리하려는 것이다. 이로써 구현 자체도 하나의 추상화 개념으로 다양한 변형이 가능해지고, 구현과 독립적으로 인터페이스도 다양함을 가질 수 있게 된다.
3. Composite
   • 부분-전체 계층을 나타내기 위해 복합 객체를 트리 구조로 만든다. Composite 패턴은 클라 이언트가 개별적 객체와 복합 객체 모두를 동일하게 다루도록 한다.
4. Decorator
   • 객체에 동적으로 책임을 추가할 수 있게 한다. Decorator 패턴은 기능의 유연한 확장을 위 해 상속 대신 사용할 수 있는 방법이다
5. Facade
   • 서브시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공한다. Facade 패턴은 서브시스템을 좀 더 사용하기 편하게 하기 위해서 높은 수준의 인터페이스를 정의한다.
6. Flyweight
   • 작은 크기의 객체들이 여러 개 있는 경우, 객체를 효과적으로 사용하는 방법으로 객체를 공유하게 한다.
7. Proxy
   • 다른 객체로의 접근을 통제하기 위해서 다른 객체의 대리자 또는 다른 객체로의 정보 보유자를 제공한다.

3. 행위 패턴

1. Chain of Responsibility (https://cyk0825.tistory.com/46)

• 요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여함으로써 요청하는 객체와 처리하 는 객체 사이의 결합도를 없애려는 것이다. 요청을 해결할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달한다.

2. Command(https://cyk0825.tistory.com/47)

• 요청을 객체로 갭슐화함으로써 서로 다른 요청으로 클라이언트를 파라미터화하고, 요청을 저장하거나 기록을 남겨서 오퍼레이션의 취소도 가능하게 한다.

3. Interpreter

• 언어에 따라서 문법에 대한 표현을 정의한다. 또 언어의 문장을 해석하기 위해 정의한 표현에 기반하여 분석기를 정의한다.

4. Iterator(https://cyk0825.tistory.com/53)

• 내부 표현 방법을 노출하지 않고 복합 객체의 원소를 순차적으로 접근할 수 있는 방법을 제공한다

5. Mediator

• 객체들 간의 상호작용을 객체로 캡슐화한다. Mediator 패턴은 객체들 간의 참조 관계를 객 체에서 분리함으로써 상호작용만을 독립적으로 다양하게 확대할 수 있다.

6. Memento

• 캡슐화를 위배하지 않고 객체 내부 상태를 객체화하여, 나중에 객체가 이 상태로 복구 가능 하게 한다.

7. Observer

• 객체 사이에 일 대 다의 종속성을 정의하고 한 객체의 상태가 변하면 종속된 다른 객체에 통보가 가고 자동으로 수정이 일어나게 한다.

8. State

• 객체의 내부 상태에 따라 행위를 변경할 수 있게 한다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다

9. Strategy

• 알고리즘군이 존재할 경우 각각의 알고리즘을 별도의 클래스로 캡슐화하고 이들을 상호 교환 가능한 것으로 정의한다. Strategy 패턴은 클라이언트에 영향을 주지 않고 독립적으로 알고리즘을 다양하게 변경할 수 있게 한다.

10. Template Method

• 오퍼레이션에는 알고리즘의 처리 과정만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스에 정의한다. Template Method 패턴은 알고리즘의 처리 과정은 변경하지 않고 알고 리즘 각 단계의 처리를 서브클래스에서 재정의할 수 있게 한다.

11. Visitor

• 객체 구조의 요소들에 수행할 오퍼레이션을 표현한 패턴이다. Visitor 패턴은 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 한다.

 

 

설명과 다이어그램만 보니까 어떤 패턴인지 정확히 감이 안오는 패턴들이 많아서 나중에 패턴별로 예시코드를 작성해보면서 공부를 해야겠습니다.

---

참고 :

 

도서 : Java 언어로 배우는 디자인 패턴 입문

GoF_의_디자인_패턴.pdf

0.50MB

 

GoF - design patterns elements of reusable object-oriented software(https://github.com/muthukumarse/books-1/blob/master/Design%20Patterns%2C%20Elements%20of%20Reusable%20Object-Oriented%20Software.pdf)