디자인 패턴(Design Pattern)은 소프트웨어 설계 과정에서 발생하는 문제들에 대한 해결책이다. 코드에서 반복되는 디자인 문제들을 해결하기 위해 맞춤화할 수 있는 미리 만들어진 청사진과 비슷하다.
일종의 설계 기법이며, 설계 방법이다
목적
sw 재사용성, 호환성, 유지보수성을 보장
특징
디자인 패턴은 하나의 아이디어로, 특정한 구현이 아니다.
패턴과 알고리즘과 자주 혼동하는데, 두 개념 모두 어떤 문제에 대한 해결책을 설명하기 때문이다.
알고리즘은 어떤 문제를 해결하기 위해 따라야 할 명확한 절차이고, 디자인 패턴은 해결책에 대한 상위 수준의 설명이다.
디자인 패턴은 결과와 기능을 제시하나 구현 단계 및 순서는 사용자가 결정한다.
프로젝트에 항상 적용해야 하는 것은 아니지만, 재사용, 호환, 유지 보수의 문제 해결을 예방하기 위해 패턴을 만들어 둔 것이다.
장점
디자인 패턴은 소프트웨어 설계의 일반적인 문제에 대해 시도되고 검증된 해결책들을 모은 것이다.
또한 디자인 패턴을 알면 팀원들 간의 효율적인 의사소통을 할수 있는 공통의 언어가 된다. 예를 들어 모든 팀원이 디자인 패턴에 대해 이해하고 있다면 '그 문제는 싱글톤으로 해결합시다'라고 말하면 모두 무슨 말인지 알아 들을 수 있고 싱글톤에 대한 개념을 따로 설명하지 않아도 된다.
SOLID, 객체지향 설계 원칙
- Single Responsibility Principle(SRP, 단일 책임 원칙)
"클래스(객체)는 단 하나의 책임만 가져야 한다"는 원칙, 여기서 '책임'은 하나의 '기능'으로 보면 된다.
만일 하나의 클래스에 기능(책임)이 여러개가 있다면 기능 수정이 일어났을때 수정해야할 코드가 많아진다. 따라서 SRP 원칙을 따름으로써 한 책임의 변경으로부터 다른 책임의 변경으로의 연쇄작용을 극복할 수 있다.
단일 책임 원칙을 잘 지키면 프로그램의 유지보수 성을 높일 수 있는 설계 기법이다. - Open-Close Principle(OCP, 개방 폐쇄 원칙)
"확장에 열려있어야 하며, 수정에는 닫혀있어야 한다"는 원칙, 기능 추가 요청이 오면 클래스 확장을 통해 손쉽게 구현하면서, 확장에 따른 클리스 수정은 최소화 하도록 설계하는 기법이다.
확장에 열려있다는 말은 새로운 변경 사항이 발생했을 때 유연하게 코드를 추가함으로써 큰 힘을 들이지 않고 기능을 확장할 수 있음을 말한다.
변경에 닫혀있다는 말은 새로운 변경 사항이 발생했을 때 객체를 직접적으로 수정을 제한함을 말한다.
간단히 말해서, OCP 원칙은 추상화 사용을 통해 관계 구축을 권장한다는 의미이다. - Liskov Substitution Principle(LSP, 리스코프 치환 원칙)
"서브 타입은 언제나 부모 타입으로 교체할 수 있어야 한다"는 원칙이다.
다형성의 특징을 이용하기 위해 상위 클래스 타입으로 객체를 선언하여 하위 클래스의 인스턴스를 받으면, 업캐스팅된 상태에서 부모의 메서드를 사용해도 동작이 의도대로 흘러가야 하는 것을 의미한다. - Interface Segregation Principle(ISP, 인터페이스 분리 원칙)
"인터페이스를 각각 사용에 맞게 잘게 분리해야 한다"는 설계 원칙이다.
SRP 원칙이 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조한다고 보면 된다.
인터페이스를 사용하는 클라이언트를 기준으로 분리함으로, 클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것이 목표다.
주의해야 할점은 한번 인터페이스를 분리하여 구성해놓고 나중에 무언가 수정사항이 생겨서 또 인터페이스를 분리하는 행위는 하지 말아야 한다. - Dependency Inversion Property(DIP, 의존 연적 원칙)
"어떤 Class를 참조해서 사용해야하는 상황이 생긴다면, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스 or 인터페이스)로 참조해야 한다"는 원칙이다.
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변하는 것 보다, 변화하기 어렵고 거의 변화가 없는 것에 의존하라는 말이다.
부작용
많은 초보자는 패턴을 배운 후, 더 간단한 코드로 문제 해결이 되는 상황에도 모든 곳에 패턴을 적용하려 한다는 부작용이 있다.
분류
- 생성 패턴(Creational): 객체 생성 방식 결정
객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.
예를 들어 DBConnection을 관리하는 Instance를 하나 만들 수 있도록 제한하여, 불필요한 연결을 막는다. - 구조 패턴(Structural): 객체간의 관계를 조직
예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 페턴이다. - 행위 패턴(Behavioral): 객체의 행위를 조직, 관리, 연합
한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.
관련 포스팅
생성 패턴
-
구조 패턴
-
행위 패턴
-
참고자료
https://gyoogle.dev/blog/design-pattern/Overview.html
https://refactoring.guru/ko/design-patterns
https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID