디자인패턴(DesignPattern)에 대하여

디자인패턴(DesignPattern)에 대하여

디자인 패턴이란?

클래스 구조를 갖는 프로그래밍을 하다보면 클래스간에 구조가 짜여지고 다양한 방법으로 객체가 생성되며 관계에 따라 여러가지 형태의 행동들이 나타납니다. 그런데 기초 설계가 제대로 되어있지 않은 상태로 프로그래밍이 시작된다면 얼마 못가 클래스 관계가 꼬일대로 꼬여 누더기 진흙탕 코드덩어리로 변하게될것입니다. 엄청나게 뛰어난 사람이어서 초기 요구에 맞춰 잘 짜여진 클래스관계를 만든다 해도 요구 사항이 바뀌게되면 쉽게 대응하지 못합니다. 

 

위 같은 상황은 OOP(Object Oriented Programming)의 특성을 잃어버리는 것입니다.

많은 사람들이 OOP에 대하여 고민했고 프로그램의 목적이 어떻든간에 프로그램안에 클래스들이 갖는 구조에는 일정한 '형태' 혹은 '패턴' 이 존재한다는 것을 인지하기 시작했습니다.

이를 바탕으로 클래스간의 관계, 클래스간의 행동양식을 분류하고 각각에 대해 객체지향적인 설계를 따르는 노하우들이 차곡차곡 정리되어 객체지향적으로 합당한 클래스 설계 형태를 정립하기 시작했고 이를 클래스 디자인 패턴 이라 이름붙이게 된 것입니다.

 

클래스 디자인 원칙(SOLID)

S 
단일 책임 원칙 (Single responsibility principle, SRP)

"한 클래스는 하나의 책임만 가져야 한다."

 

클래스는 자신의 이름이 나타내는 일 하나만을  해야한다.

 

O 

개방-폐쇄 원칙 (Open/closed principle, OCP)

“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”

 

요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며,

기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻입니다.

변경이 발생하는 부분을 추상화 하여 분리하여관리 코드의 수정을 최소화하여 결합도는 줄이고 응집도는 높여야합니다.

 

L 
리스코프 치환 원칙 (Liskov substitution principle, LSP)

“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 

 

다형성과 확장성을 극대하기위해 하위 클래스를 사용하는 것보다는 상위의 클래스(인터페이스)를 사용을 지향해야한다.

 

ex1) List 나 Set으로 타입을 선언하여 사용하는것보다, Collection으로 선언하여 사용하는것이 좋습니다.

ex2) ArrayList나 LinkedList를 사용할때 , 타입을 List로 선언하여 사용하는것이 좋다.

 

I 
인터페이스 분리 원칙 (Interface segregation principle, ISP)

"하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다."

 

한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리

 

D 
의존관계 역전 원칙 (Dependency inversion principle, DIP)

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

 

상위 레벨의 레이어가 하위 레벨의 레이어를 바로 의존하게 하는 것이 아니라 이 둘 사이에 존재하는 추상레벨을 통해 의존해야 합니다.

이를 통해서 상위레벨의 모듈은 하위레벨의 모듈로의 의존성에서 벗어나 그 자체로 재사용 되고 확장성도 보장 받을 수 있습니다.

 

https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

 

생성 패턴(Creational Patterns)

추상 팩토리 패턴 : 동일한 주제의 다른 팩토리를 묶어 준다.  

빌더 패턴 : 생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성한다  

팩토리 메서드 패턴 : 생성할 객체의 클래스를 국한하지 않고 객체를 생성한다.  

프로토타입 패턴 : 기존 객체를 복제함으로써 객체를 생성한다.  

싱글톤 패턴 : 한 클래스에 한 객체만 존재하도록 제한한다.

 

구조 패턴(Structural Patterns)

어댑터 패턴 : 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌운다.  

브리지 패턴 : 추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있다.  

합성 패턴 : 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있다.  

데코레이터 패턴 : 기존 객체의 매서드에 새로운 행동을 추가하거나 오버라이드 할 수 있다.  

파사드 패턴 : 많은 분량의 코드에 접근할 수 있는 단순한 인터페이스를 제공한다.  

플라이웨이트 패턴 : 다수의 유사한 객체를 생성·조작하는 비용을 절감할 수 있다.  

프록시 패턴 : 접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공한다.

 

행위 패턴(Behavioral Patterns)

책임연쇄 패턴(Chain of responsibility) : 일련의 처리 객체들에 명령을 대행  

커맨드 패턴 : 작업(action)과 매개변수를 묶어놓은 객체를 생성  

해석자 패턴 (Interpreter pattern) : 특정 언어를 구현  

반복자 패턴 (Iterator pattern) : 내부 구조를 드러내지 않고 객체의 구성요소들을 순차적으로 접근  

중개자 패턴 (Mediator pattern) : 둘 이상의 클래스가 가지고 있는 매서드 들을 알고 있는 유일한 클래스로 클래스들을 느슨하게 연결  

메멘토 패턴 (Memento pattern): 객체를 이전 상태로 복구하는 능력 제공  

옵저버 패턴 : 옵저버 객체들이 이벤트를 볼 수 있게 하는 패턴

 

 

위와 같이 많은 패턴들에 대하여 ,

싱글톤은 기본이고 그 외 평소 본인이 써본 패턴에 대해서는 공부하는게 좋을것 같습니다.

다음 글에서 부터

 

 

 

https://ko.wikipedia.org/wiki/%EB%94%94%EC%9E%90%EC%9D%B8_%ED%8C%A8%ED%84%B4_(%EC%B1%85)

디자인 패턴 (책) - 위키백과, 우리 모두의 백과사전