소프트웨어 공부를 하다보면 자료구조 만큼이나 자주 등장하는 디자인 패턴이다.
그렇다면 디자인 패턴은 과연 무엇을 의미하는걸까?
디자인 패턴
💬 : 소프트웨어 설계 과정에서 자주 발생하는 문제들에 대한 일반적인 해결책들을 의미한다.
알고리즘과 다른 점 🤔
여기서 헷갈릴 수 있는 점, 알고리즘과 디자인 패턴이 같은 의미가 아닌가?
왜냐하면 두 개 전부 문제에 대한 해결책을 설명하기 때문이다.
하지만 엄연히 다르다.
알고리즘
💡 : 어떤 목표를 달성하기 위해 따라야 할 명확한 일련의 절차를 정의한다.디자인 패턴
💡 : 알고리즘에서 의미하는 해결책에 대한 더 상위 수준의 설명이다.
✅ 알고리즘은 요리법에 비유할 수 있으나, 패턴은 요리법이 아닌 청사진(Blueprint)에 더 가깝다.
✅ 두 개 모두 해결을 위한 명확한 단계들이 제시되어 있다.
✅ 청사진은 결과와 기능은 제시하지만 구현 단계 및 순서는 설계자, 즉 사용자가 결정한다.
패턴을 배워야 하는 이유?
사실 프로그래머가 패턴에 대해 알지 못해도 상관이 없다.
프로그래머가 패턴에 대한 지식이 전무해도 업무를 수행하는데 지장이 없다고 한다.
또 자신이 모르는 사이에 패턴들을 이미 구현하고 사용하고 있을수도 있다.
그렇다면 왜 패턴을 사용해야할까?
일반적인 문제들의 검증된 해결책
✅ 디자인 패턴은 소프트웨어에서 발생하는 일반적인 문제들에 대하여 시도되고 검증된 해결책들을 모은 것이다.
✅ 문제들을 다루지 않더라도 패턴을 배우게 되면 객체 지향 디자인의 원칙들을 사용하여 많은 종류의 해결 방법을 배울 수 있다!
협업 시 의사소통의 원활
✅ 팀원끼리의 프로젝트 설계 또는 개발 시 효율적으로 의사소통하는 데 사용할 수 있는 공통 언어를 정의해준다.
하나의 대화를 예로 들어보겠다.
🗣️ 팀원 A : 이거 어떻게 하면 더 메모리 낭비가 안될까요 ...?
🤷♂️ 팀원 B : 그거 그냥 싱글톤(
Singleton) 사용하시면 될 껍니다.
🗣️ 팀원 A : 😓? 그게 뭐에요?
🤷♂️ 팀원 B : 🤦♂️.. 먼저 생성자를
private으로 만드시고..~!#@..
만약 팀원 A가 디자인 패턴 중 하나인 싱글톤 패턴을 숙지했었다면 팀원 B가 싱글톤에 대한 설명을 전부 다 할 필요가 없다는 뜻이다.
❗패턴의 단점
그렇다고 해서 패턴이 꼭 좋은것이냐? 라고하면 아니다. 패턴에 대한 비판도 많다.
❗비효율적인 해결책
- 패턴은 문제 해결 방식의 체계화이기 때문에, 많은 사람들이 패텅들을 적재적소에 사용하는 것이 아닌 패턴의 문자 그대로로 구현 할수있다.
❗부당한 사용
망치만 있으면 모든 것이 못처럼 보이게 된다.
- 하나의 해결책이 있다면, 더 간단한 코드로도 쉽게 해결될 수 있는 상황에서도 모든 곳에 패턴을 적용할 수 있다.
패턴의 종류
디자인 패턴은 의도와 목적에 따라 분류 된다.
크게 3가지로 분류되며 생성 패턴, 구조 패턴, 행동 패턴으로 분류된다.
생성 패턴
💡: 생성 패턴들은 기존 코드의 재활용과 유연성을 증가시키는 객체(인스턴스) 생성 메커니즘을 제공해준다.
- 추상 팩토리(
Abstract Factory) - 팩토리(
Factory Method) - 빌더(
Builder) - 프로토타입(
Prototype) - 싱글톤(
SingleTon)
구조 패턴(객체 결합)
💡: 구조 패턴은 구조를 유연하고 효율적으로 유지하며 객체 & 클래스를 더 큰 구조로 조합하는 방법이다.
- 브릿지(
Bridge) - 파사드(
Facade) - 어댑터(
Adapter) - 래퍼(
Wrapper) - 복합체 패턴(
Composite) - 프록시(
Proxy)
행동 패턴
💡: 행동 패턴은 객체(
인스턴스)간의 효과적인 의사소통과 책임 할당을 처리해준다.
- 책임 연쇄(
Chain of Responsibility) - 커맨드(
Command) - 반복자(
Iterator) - 중개인(
Mediator) - 옵저버(
Observer) - 외 몇 개의 행동패턴들
마치며
요즘 자격증 준비하며 디자인 패턴들도 약간 맛 봤는데 정말 좋은 공부요소이다.
디자인 패턴은 꾸준히 공부하고 다뤄봐야겠다.
💬 참고 자료
