Design Pattern 개요
개발자라면 꼭 숙지해야 할 디자인 패턴에 대해 깊이있게 공부하고, 실무 적용방법을 연구하기 위한 글.
디자인 패턴이란?
소프트웨어 설계에서 일반적이고 재사용 가능한 추상화된 문제의 해결책. -> Best Practice의 공식화
디자인 패턴의 구성요소
- 문제 : 해결할 문제와 그 배경을 설명
- 해법 : 설계를 구성하는 요소들과 그 요소들 간의 관계, 책임 및 협력 관계
- 디자인 패턴을 적용해서 얻은 결과와 장단점
SOLID 원칙
SOLID 원칙이란 객체지향 설계에서 지켜야 할 5개의 원칙이다. 예상치 못한 변경사항에 유연하게 대처하며, 확장성있는 구조를 설계하기 위해 원칙을 지키는 것이 중요하다.
SOLID
- SRP(Single Responsibility Principle - 단일 책임 원칙)
- 소프트웨어의 설계 부품(클래스, 함수 등)은 하나의 책임만을 가져야 한다.
- 책임(기능)을 분리시켜 결합력을 낮춰 유지보수에 용이하도록 설계해야함.
- OCP(Open-Closed Principle - 개방-폐쇄 원칙)
- 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수(Open) 있도록 설계해야 함.
- 변경되는 것이 무엇인지에 초점을 맞추어야 함. (ex.인터페이스를 이용하여 명세의 변경 없이 기능의 수정, 추가가 가능)
- LSP(Liskov Substitution Principle - 리스코프 치환 원칙)
- 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 함.
- 부모와 자식클래스 사이의 행위에는 일관성이 있어야 함.
- 객체 지향 프로그래밍에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용해도 문제가 없어야 한다는 것을 의미.
- 상속 관계에서 일반화 관계(IS-A)가 성립해야 함 => 일반화 관계에 대한 원칙
- DIP(Dependency Inversion Principle - 의존 역전 원칙)
- 의존 관계를 맺을 때, 변화하기 쉬운 것 보단 변화하기 어려운 것에 의존해야 함.
- 변화하기 쉬운 것 -> 구체적인 것(구체화 된 클래스) / 변화하기 어려운 것 -> 추상적인 것(추상클래스, 인터페이스)
- 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미
- ISP(Interface Segregation Principle - 인터페이스 분리 원칙)
- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. / 하나의 일반적인 인터페이스보다, 여러 개의 구체적인 인터페이스가 낫다.
- 자신이 사용하지 않는 기능에는 영향을 받지 말아야 한다는 의미.
- 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포가 쉽게 가능.
좋은 설계란?
시스템에 새로운 요구사항이나 변경사항이 있을 때, 영향을 받는 범위가 적은 구조
디자인 패턴들은 SOLID원칙에 입각하여 만들어진 것임.
디자인 패턴의 분류
- Creational
- Factory Method
- Abstract Factory
- Builder
- Prototype
- Singleton
- Structural
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
- Behavioral
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template Method
- Visitor
각 패턴에 대해 상세하게는 이후에 하나씩 다룰 예정.
참고
- https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99
- https://gmlwjd9405.github.io/2018/07/06/design-pattern.html