Design Pattern

객체지향 설계는 다음 5가지 원칙을 지키면서 개발해야한다.

S: Single responsibility principle(SRP)

• 단일 책임 원칙
• 한 클래스는 하나의 책임만 가져야 한다

O: Open/closed principle(OCP)

• 개방-폐쇄 원칙
• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

L: Liskov substitution principle(LSP)

• 리스코프 치환 원칙
• 프로그램의 객체는 프로그램의 정확성은 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

I: Interface segregation principle(ISP)

• 인터페이스 분리 원칙
• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다

D: Dependency inversion priciple

• 의존관계 역전 원칙
• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다.

[나무위키]

객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴.

여러 사람이 협업해서 개발할 때 다른 사람이 작성한 코드, 기존에 존재하는 코드를 이해하는 것은 어렵다. 이런 코드를 수정하거나 새로운 기능을 추가해야 하는데 의도치 않은 결과나 버그를 발생시키기 쉽고 성능을 최적화시키기도 어렵다. 이로 인해 시간과 예산이 소모된다.

디자인 패턴은 의사소통 수단의 일종으로서 이런 문제를 해결해준다. 예를 들어 문제 해결의 제안에 있어서도 “기능마다 별도의 클래스를 만들고, 그 기능들로 해야할 일을 한번에 처리해주는 클래스를 만들자.”라고 제안하는 것보다 "Facade 패턴을 써보자."라고 제안하는 쪽이 이해하기 쉽다.

일반 프로그래머가 만나는 문제가 지구상에서 유일한 문제일 확률은 거의 없다. 이미 수많은 사람들이 부딪힌 문제다. 따라서 전문가들이 기존에 해결책을 다 마련해 놓았다.

다만 과유불급. 디자인 패턴을 맹신한 나머지 모든 문제를 패턴을 써서 해결하려 드는 패턴병에 걸리지 않도록 조심하자. 디자인 패턴보다 중요한 것은 코드베이스의 간결성이다. 즉 디자인 패턴 적용이 굳이 필요가 없을 것 같은 부분은 적용하지 않는게 상책이다. 디자인 패턴은 알고리즘이 아니라 상황에 따라 자주 쓰이는 설계 방법을 정리한 코딩 방법론일 뿐이며 모든 상황의 해결책이 아니다. 디자인 패턴에 얽매이는 것보단 그 패턴이 왜 효율적인 방식인지를 이해해야 한다. 같은 이름의 패턴이 다른 언어로 구현된 모습을 보면 이에 대해 좀 더 쉽게 이해할 수 있을 것이다.

 

위는 나무위키에 적혀있는 정의 내용으로 디자인 패턴은 간단하게 객체지향 프로그래밍에서 여러 문제에 대한 해결책, 패턴 말한다.

 

3. 디자인 패턴의 종류

이미 알려진 디자인 패턴은 다음과 같이 23개로 나누어져있다.
이는 GoF(Gang of Four) 디자인 패턴이라고 불리며, 4명의 유명한 개발자들에 의해 고안되었다.

생성 패턴 (Creational patterns)구조 패턴 (Structural patterns)행동 패턴 (Behavioral patterns)

싱글톤 (Singleton)	어댑터 (Adapter)	스트레티지 (Strategy)
팩토리 메쏘드 (Factory Methods)	브리지 (Bridge)	템플릿 메쏘드 (Template Meothods)
추상 팩토리 메쏘드 (Abstract Factory Methods)	컴퍼지트 (Composite)	옵저버 (Observer)
빌더 (Builder)	데코레이터 (Decorator)	스테이트 (State)
프로토타입 (Prototype)	퍼사드 (Facade)	비지터 (Visitor)
	플라이웨이트 (Flyweight)	커맨드 (Command)
	프록시 (Proxy)	인터프리터 (Interpreter)
		이터레이터 (Iterator)
		미디에이터 (Mediator)
		메멘토 (Memento)
		책임 연쇄 (Chain of Responsibility)

하위 카테고리에서 해당 패턴들을 하나하나 설명하고 연습하도록 하겠습니다.