[Design Pattern]디자인 패턴

https://en.wikipedia.org/wiki/Software_design_pattern

여러 설명을 듣고싶으면 이걸 보도록 하자.

예전에 프로그래밍을 막 배우기 시작할 때 교내 연구실 구석에 꽂혀있는 디자인 패턴책을 보면서 이게 뭔내용이지 하고 궁금해했던 기억이 있다.

사실 그 때의 궁금함은 말그대로 뭐지? 궁금하다 정도였고 깊게 생각하진 않았다. 사실 그렇게 깊게 관심이 있진 않았다.

그러나 나중에 디자인 패턴에 관심을 갖게 된건 캡스톤 디자인을 하기 위해서 남의 코드를 보면서 생겼다.

그 때 Password관리 프로그램을 만들기 위해서 오픈소스를 뜯어보면서 참고하고 있던 도중에 봤던 코드이다.

그 때 필자가 확인했던 패스워드 관리 프로그램은 Open Source인 Password Safe였다.

디자인은 구리지만 꽤 괜찮은 툴이다. 요즘엔 더 좋은게 많지만.

여기서 이 코드를 보고 감이 딱 오는가?

이 코드를 보면 신비한점이 있다.

1. private로 생성자를 제한하며

2. 자기자신의 형태를 클래스 필드로 가지고있고

3. 그리고 getInstance로 자기 자신을 반환할 수 있다는 점이다.

이 디자인 패턴은 시작?의 디자인패턴이라고도 할 수 있는 매우 유명하고 유용한 singleton패턴이다.

그렇다고 진짜 최초의 디자인 패턴이라는 뜻은 아니고 그만큼 유용하고 범용적이라는 것이다.

싱글턴패턴의 목적은 단한개이다. 객체를 한개를 만들것이라는 것.

이런식으로 특정한 문제를 해결하기 위해서 만들어진 코딩 패턴을 디자인 패턴이라고 한다.

가령 여러분이 특정 객체를 한개를 만들기 위한 방법은 여러가지가 있을 것이다. 그걸 설명할때

"그거 생성자는 private으로 두고 instance 변수를 자타입으로 짠다음에 그걸 static을 걸어, 그 다음 그걸 static 메소드 getInstance로 반환하는 거야."

라고 말하기 보단. "싱글턴 패턴으로 짤거야"라고 말하는게 훨씬 쉽다.

프로그래밍은 추상적인 개념을 마구마구 사용하는데 거기에 대한 용어도 필요하다.

그 합의 점이 디자인 패턴인 것이다.

단일 책임 원칙 ( Single Responsibility Principle : SRP )

- 객체는 한개의 책임만을 지어야한다.

추상적인 개념이라서 지키기 조금 힘들지만 최대한 한개의 역활로만 존재하는 객체를 만드려 노력한다.

개방-폐쇄 원칙 ( Open-Closed Principle: OCP )

- 쉽게 이야기해서 A객체를 사용하는 B객체의 경우 A의 기능을 수정하기 위해서 B까지 고치지 않게 한다는 것이다.

하지만 강하게 의존하는 두 객체 역시 필연적으로 존재할 수 있기 때문에 최대한 노력하려고 한다가 맞는 것이다. 

리스코프 치환 원칙 ( Liskov Substitution Principle: LSP )

- 상속관계의 부모객체를 자식객체로 치환해도 문제 없이 작동해야한다.

인터페이스 분리 원칙 ( Interface Segregation Principle: ISP )

-말그대로 인터페이스를 최대한 쪼개야한다는 것이다. 그래야 유연한 코드를 짤 수 있기 때문이다.

의존 역전 원칙 (Dependency inversion Principle: DIP )

-A객체를 사용하는 B객체는 A객체에 강하게 의존하고 있다. 이를 역전시켜서 약결합을 만드는 것이 목표이다.

사실 이 개념은 DI를 제대로 알아야 설명할 수 있는게 뭐 그냥 그렇구나 하고 넘어가자.

즉 디자인 패턴은 SOLID를 지키는 방향으로 발전하는 경향이 있다.

물론 모든 디자인 패턴이 위 원칙을 강하게 지키려고 하지는 않는다.

디자인 패턴의 분류는 4종류가 있다.

3종류로 분류하는 곳도 있지만 필자는 보통 4종류로 분류하는 편이다.

생성 패턴 (Creational Pattern) : 객체의 인스턴스 생성을 위한 패턴이다.

행동 패턴 (Behavioral Pattern) : 클래스와 객체들이 상호 작용하는 방법 과 연활을 분담하는 방법을 위한 패턴이다.

구조 패턴 (Structurla Pattern) : 클래스 및 객체를 이용하여 더 큰 구조로 만드는 패턴

병행 패턴 (Concurrency pattern) : 멀티 스레딩 환경 및 병행성 해결을 위해 사용하는 패턴

보통 병행 패턴은 기타 패턴으로 분류하는 곳도 있다.

만약 3종류를 골라라고 하면 생성, 행동, 구조 라고 언급하면 될 것이다.

여기서 필자가 들은 디자인 패턴에 대한 질문의 답을 몇개 해드리려고 한다.

1.디자인 패턴은 언어에 종속적인가?

2.디자인 패턴은 항상 유용한가?

먼저 디자인 패턴은 언어에 종속적인 것인가? 라는 질문이다.

정답은 그런 디자인 패턴도 있고 아닌 패턴도 있다.

프로그래밍을 하면서 일종의 패턴은 모두 디자인 패턴인데 특정언어에만 강하게 필요한 패턴도 있고

반대로 특정 언어에는 필요없는 패턴들이 있다.

전자의 예로는 C언어의 경우 객체가 없으므로 다양한 객체 패턴들이 존재한다.

winapi class pattern은 winapi전역에 널리 사용되고 있고 cpp class pattern역시 리눅스 커널단에서 자주 사용되고 있다.

이런 디자인 패턴은 객체를 지원해주는 대부분의 언어에서는 고려대상조차 되지 않는다.

후자의 예로는  스트레티지패턴, 즉 전략패턴은 자바에서는 매우 유용하지만 파이썬이나 js에서는 원래 덕타이핑이 되므로 필요없다.

그리고 java라 할지라도 spring에서 몇가지 디자인패턴들을 프레임워크단에서 지원해주므로 고려하지않고 짜도 되는 경우가 많다.

두번째로 디자인 패턴은 항상 유용한가? 라는 질문이다.

정답은 그렇지 않다.

디자인 패턴은 여러 문제를 해결해준다. 특히 언어차원에서 힘든 문제를 해결해주는 매우 고마운 패턴들이 많다.

그러나 과하게 쓰는건 절대 좋지 않다.

디자인 패턴을 쓰면 쓸수록 추상화가 계속해서 진행되므로 코드 깊이가 깊어져서 읽기 매우 힘들어진다.

또한 진입장벽이 높아지는 결과를 낳기도 한다.

실제로 여러 오픈소스를 보다보면 디자인 패턴을 적극 활용해서 짠 코드와 그렇지 않은 코드들중 후자가 압도적으로 읽기 쉽다.

마지막으로 디자인패턴 졸라 과하게 쓰지는 마라. 개 읽기 힘드니까. 빌더패턴으로 nodejs코드마냥 짜는 사람 봤는데 하나도 안 멋있으니까 이상한짓 하지마라.