이 게시물은 다음의 자료를 참고하고 있습니다.
개발을 진행하다 보면 우리는 여러 가지 상황을 마주하게 됩니다.
그 상황을 타개하는 방법은 한 가지 일 수도 있고 여러 가지 일 수도 있죠
개발자는 효율성, 안정성, 가용성 등을 고려해 현재 프로젝트의 배경에서 가장 적합한 방법을 선택해서 개발을 진행하게 될 것입니다.
그러다 보면, 특정한 방식으로 개발을 반복적으로 하게 되겠죠
과도기를 거치면 성숙애 지듯이 개발의 방법도 여러 가지 였다가 살아남은 몇 가지 방식들이 존재합니다.
우리는 이를 방법론, 루틴 등 여러 가지 방식으로 부를 수 있겠지만, 개발자들은 '패턴' 이라는 용어를 선택했죠
오늘 제가 이야기할 주제는 '디자인 패턴입니다.'
디자인 패턴이 뭔데??
디자인 패턴이란
디자인 패턴은 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 전형적인 해결책입니다. 이는 코드에서 반복되는 디자인 문제들을 해결하기 위해 맞춤화할 수 있는 미리 만들어진 청사진과 비슷합니다.
Refactoring Guru
소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
위키백과 소프트웨어 디자인 패턴
위의 두 사이트의 설명과 같이 정형화된 개발의 패턴입니다!!
쉽게 말해 '이렇게 코딩하면 이러이러한 이득을 얻을 수 있다!' 라고 생각하시면 편할 듯 하네요
카테고리
디자인 패턴에는 크게 3가지 종류가 존재합니다
- 생성 패턴 (Creational Pattern)
- 구조 패턴 (Structal Pattern)
- 행위 패턴 (Behavial Pattern)
각 패턴의 간단한 설명과 예제들은 다음과 같습니다
생성 패턴
주로 객체를 인스턴스화 시킬 때 사용되는 방법입니다.
객체들을 얼마나 강하게, 약하게 결합시킬 지 결정하는 패턴입니다
- 추상 팩토리 Abtract Factory
- 빌더 Builder
- 팩토리 매서드 Factory Method
- 프로토타입 Prototype
- 싱글톤 Singleton
구조 패턴
구조 패턴은 더 큰 구조를 구성하기 위해 클래스와 객체를 결합하는 방법을 제공합니다.
상속이나 composition을 사용해서 사용자의 소프트웨어의 유연함과 적용 가능함(adaptable)을 제공할지 결정하죠
- 어댑터 Adapter
- 브릿지 Bridge
- 복합체 Composite
- 데코레이터 Decorator
- 파사드 Facade
- 플라이웨이트 Flyweight
- 프록시 Proxy
행위 패턴
행위 패터은 객체들 사아의 상호 작용을 조정하는 패턴입니다
- 책임 연쇄 Chain of Responsibility
- 커맨드 Command
- 반복자 Iterator
- 인터프리터 Interpreter
- 중재자 Meditator
- 메멘토 Memento
- 옵서버 Observer
- 상태 State
- 전략 Strategy
- 템플릿 메소드 Template Method
- 방문자 Visitor
그 외
- 널 객체 Null Object
- 심플 팩토리 Simple Factory
- MVC Model - View - Controller
- 계층 Layers
굉장히 많군요...!!!
이렇게 많은 패턴들을 앞으로 하나씩 자세히 들여다 볼 계획입니다!!
예제 코드는 Java Design Pattern 2nd 에서 가져왔습니다
여기 -> 깃허브 가시면 볼 수 있어요!!
해당 코드의 관계도는 다음과 같습니다
디자인 패턴의 원칙
마지막으로 책에서 알려주는 디자인 패턴에서 일관적으로 지키려고 노력하는 객체지향적 원칙 4가지를 소개하고 마차겠습니다.
1. Program to an interface, not an implementation
구현체보다는 추상체를 사용해라
여기서 interface란 자바에서 추상체를 의미합니다. 단순히 인터페이스가 아니라, 추상 클래스도 포함하는 의미이죠!!
즉, 구체적인 타입을 딱 찍어서 개발을 진행하기 보다는 일반적으로 더 사용할 수 있는 타입으로 변수, 메소드 인자, 생성자를 선언해아 합니다.
이렇게 추상적으로 개발을 진행하면 런타임시 실제 타입이 대응 될 때, 더 유연하게 프로그램이 동작할 수 있습니다!
2 Prefer object composition over inheritance
객체를 다룰 때 상속 보다는 composition을 사용해라
객체간의 관계를 맺을 때, is - a와 has - a의 차이점을 명확히 구별해서 사용해야 합니다.
위의 다이어그램의 Vehicle 클래스와 Engine 클래스를 한 번 보겠습니다.
분명히 AbstractCar 는 Vehicle 입니다 (AbstractCar is a Vehicle)
하지만 Vehicle 은 Engine이 아닙니다 (Vehicle is not a Engine)
그렇지만 Vehicle 은 Engine을 가지고 있죠! (Vehicle has a Engine)
그렇기 때문에 AbstractCar 클래스와 Saloon사이의 관계를 상속이 맞고,
Engine 클래스와 Vehicle 클래스 사이의 관계를 composition으로 연관되는게 더 자연스럽겠죠
이 부분이 객체 지향의 특성이 가장 잘 들어나는 부분이라고 개인적으로 생각합니다.
객체 지향은 실제 세계를 그대로 코드로 옮길 수 있다는 특징이 있죠
그렇기 때문에 is-a , has-a 와 같은 관계를 가지고 있고, 이를 코드로 자연스럽게 (사람이 이해하기 편하게) 적용시킬 수 있는 것이겠죠
그럼 왜 상속이 아니라 composition을 더 선호하라는 걸까요???
바로 유연성 때문입니다.
is-a 관계보다 has-a관계가 더 유연하게 동작하기 때문에 상속보다는 composition을 더 권장하는 것이죠!!
위의 방식을 이용하는 대표적인 패턴이 바로 Decorator 패턴입니다!!
3. Keep objects loosely-coupled
객체들간의 관계를 느슨하게 유지해라
이상적으로는, 하나의 클래스는 하나의 모델로 가져야 합니다.
그리고 해당 클래스를 진정으로 필요로 하는 클래스에 포함 되어야만 합니다.
위의 다이어그램에서 Vehicle 클래스가 Engine 클래스를 내부에 포함하고 있는 것 처럼 말이죠
다른 클래스를 사용할 때는 진짜로 이 클래스를 구성할 때 필요한 녀석인지 한 번 쯤은 고민을 더 해봐야 합니다..
예를 들면 IPhone 클래스는 Vehicle 클래스를 구성할 때 필요할까요???
이렇게 클래스 간의 관계를 느슨하게 유지하면 해당 클래스의 재사용성 이 늘어나는 장점을 얻을 수 있습니다!!
대표적인 예시는 Observer 패턴입니다
4. Encapsulate the concept that varies
다양한거를 캡슐화를 해라
코딩을 하다 보면 유사한 부분이 나올 때가 많죠.
그러면 이전에 이미 구현한 부분을 추출해서 사용하는 방법도 고려해보세요
대표적으로 Strategy 패턴이 여기에 해당합니다.
