1. 디자인 패턴이란
디자인 패턴은 소프트웨어 공학론 안의 좋은 코드를 설계하기 위한 일종의 설계 디자인 방법론이다.
좋은 코드란 무엇인가?
디자인 패턴에서 좋은 코드란 설계적 관점에서의 좋은 코드를 말한다.
즉, 확장과 유지보수를 하기 용이하게 설계를 하여 이후에도 추가적인 수정 등에 비용이 적게 들어가는 코드를 말한다.
높은 응집도와 낮은 결합도
객체 지향적으로 생각하면 추구해야 할 설계 방향이다.
이러한 좋은 코드를 설계하기 위해서 '객체지향 방법론'에서는 SOLID 원칙이 있다.
2. SOLID 원칙 (객체지향 5대 원칙)
1. SRP (Single Responssiblity Principle, 단일 책임 원칙)
- 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다.
여기서 책임이란, '기능' 이라고 해석하면 된다.
클래스, 함수가 비대해지면 이를 분리시킬 필요가 있으며 설계를 잘한 프로그램은 기본적으로 새로운 요구사항과 프로그램 변경에 영향을 받는 부분이 적다. 이렇게 높은 응집도와 낮은 결합도를 가진 프로그램은 내부의 함수끼리 결합이 낮으므로 이는 유지보수에 비용이 적게 들어갈 수 밖에 없다.
2. OCP (Open-Closed Principle, 개방-폐쇄 원칙)
- 기존 코드 변경에는 닫혀있고, 추가나 확장에는 열려있어야 한다.
OCP에 만족하는 설계를 할 때 변경되는 것이 무엇인지에 초첨을 맞춘다. 자주 변경될 수 있는 내용은 수정하기 쉽게 설계해야 하고, 자주 변경되지 않을 내용은 수정에 영향받지 않게 설계해야 한다.
3. LSP (Liskov Substitution Principle, 리스코프 치환 원칙)
- 자식 클래스는 부모 클래스에서 가능한 행위를 수행할 수 있어야 한다.
이는 부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙이며, 이는 객체 지향 프로그래밍에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용해도 문제가 없어야 한다는 것을 의미한다.
이는 파생 클래스를 만들 때, 이게 정말 올바른 상속의 관계를 갖는지 생각해보아야 한다.
4. DIP (Dependenct Inversion Principle, 의존 역전 원칙)
- 의존 관계를 맺을 때, 변화하기 쉬운 것 보단 변화하기 어려운 것에 의존해야 한다.
- 변화하기 쉬운 것 = 구체적인 것 (클래스, 서브 클래스 인스턴스)
변화하기 어려운 것 = 추상적인 것 (추상 클래스, 인터페이스)
따라서 DIP를 만족한다는 것은 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미한다.
이는 '의존성 주입'이라는 기술로 변화에 유연한 설계를 할 수 있다.
5. ISP (Interface Segregation Principle, 인터페이스 분리 원칙)
- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다는, 여러개의 구체적인 인터페이스가 낫다.
이는 자신이 사용하지 않는 기능(인터페이스)에는 영향을 받아서는 안된다는 의미다. -> 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.
큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 한다. -> 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙
3. 디자인 패턴의 종류
현재 알려진 디자인 패턴은 다음과 같이 23개로 나누어져있다.
이는 GoF (Gang of Four) 디자인 패턴이라고 불린다.
생성 패턴 (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) |
참조문서
https://dailyheumsi.tistory.com/148
https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99
'IT knowledge > GoF & Architecture' 카테고리의 다른 글
Layered Architecture (계층화 아키텍처) 란 무엇인가? (0) | 2023.03.13 |
---|---|
[디자인 패턴] 데코레이터 패턴(Decorator Pattern) 정리 및 예제 - 구조패턴 (0) | 2021.04.15 |
[디자인 패턴] 싱글톤 패턴(Singleton Pattern) 정리 및 예제 - 생성 패턴 (4) | 2021.04.14 |
[디자인 패턴] 디자인 패턴(Design Pattern) 이란? - 개념 및 분류(생성 패턴, 구조 패턴, 행동 패턴) (0) | 2021.04.13 |
[디자인 패턴] 어댑터 패턴(Adapter Pattern) 개념 정리 및 예제 - 구조 패턴 (0) | 2021.04.08 |