20240214

https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EB%94%94%EC%9E%90%EC%9D%B8_%ED%8C%A8%ED%84%B4

소프트웨어 디자인 패턴 - 위키백과, 우리 모두의 백과사전

 

https://namu.wiki/w/%EB%94%94%EC%9E%90%EC%9D%B8%20%ED%8C%A8%ED%84%B4

디자인 패턴

 

"객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴.

여러 사람이 협업해서 개발할 때 다른 사람이 작성한 코드, 기존에 존재하는 코드를 이해하는 것은 어렵다. 이런 코드를 수정하거나 새로운 기능을 추가해야 하는데 의도치 않은 결과나 버그를 발생시키기 쉽고 성능을 최적화시키기도 어렵다. 이로 인해 시간과 예산이 소모된다.

디자인 패턴은 의사소통 수단의 일종으로서 이런 문제를 해결해준다. 예를 들어 문제 해결의 제안에 있어서도 “기능마다 별도의 클래스를 만들고, 그 기능들로 해야할 일을 한번에 처리해주는 클래스를 만들자.”라고 제안하는 것보다 "Facade 패턴을 써보자."라고 제안하는 쪽이 이해하기 쉽다.

일반 프로그래머가 만나는 문제가 지구상에서 유일한 문제[1]일 확률은 거의 없다. 이미 수많은 사람들이 부딪힌 문제다. 따라서 전문가들이 기존에 해결책을 다 마련해 놓았다.[2]

다만 과유불급. 디자인 패턴을 맹신한 나머지 모든 문제를 패턴을 써서 해결하려 드는 패턴병에 걸리지 않도록 조심하자.[3] 디자인 패턴보다 중요한 것은 코드베이스의 간결성이다. 즉 디자인 패턴 적용이 굳이 필요가 없을 것 같은 부분은 적용하지 않는게 상책이다. 디자인 패턴은 알고리즘이 아니라 상황에 따라 자주 쓰이는 설계 방법을 정리한 코딩 방법론일 뿐이며 모든 상황의 해결책이 아니다. 디자인 패턴에 얽매이는 것보단 그 패턴이 왜 효율적인 방식인지를 이해해야 한다. 같은 이름의 패턴이 다른 언어로 구현된 모습을 보면 이에 대해 좀 더 쉽게 이해할 수 있을 것이다.
~~~
디자인 패턴 자체가 처음 개발될 때는 수학적인 엄밀화보다 현업에서 개발자들이 이렇게 저렇게 하는 예시로 출발했지만 지금은 범주론 같은 상당히 수학 이론들로 엄밀화가 되고 있고, "Expression Problem" 같은 어려운 소프트웨어 확장성 문제를 푸는 모습을 볼 수 있다.

그래서 여기까지 오면 사실상 하스켈같은 언어도 씹어먹게 되고, 그런 괴수들이 논문을 쓰고 발전을 이끌어가는 분야이다. "소인수분해를 하라"는 등 단순한 문제들은 디자인 패턴에 필요 없이, 닫힌 자료 구조와 함수만으로 풀 수 있고, 그게 최선인 경우가 많지만 현업에서는, 상당히 열려 있고 애매한 문제를 풀어야 하는 경우가 많은데 예를 들면 게임을 만드는데 캐릭터도 추가하고 스킬도 추가하고 게임의 종류도 바꾸라는 등, 모든 걸 일반적인 객체, 함수로 튜닝하는 여지를 남겨두고 개발해야 하기 때문에 디자인 패턴에 대해 머리 아픈 고민을 해야 하는 경우가 많다.

학생 때는, 위와 같이 소인수분해를 하라는 등 닫힌 문제만 주로 풀기 때문에 사실 와닿지도 않다. 또한 위에서 나왔듯이 재대로 이해하려면 범주론이나 타입 이론에 대한 지식이 필요하기 때문에 현업에서도 고수들이 아니면 디자인 패턴을 재대로 이해하는 경우는 드물다. 사실 위에서 말한 소프트웨어 무한 확장 난제 풀이가 디자인 패턴의 핵심이라고 볼 수 있다. 그게 아닌 경우 디자인 패턴이 사소하거나 확장에 발목을 잡는 경우도 많기 때문에 주의하자."

 

 

 

 

https://refactoring.guru/ko/design-patterns

디자인 패턴들

 

 

----------------------------------

나만 이거 읽고 생각하고 예시보고 하는데에 몇시간 걸리는건가...
와 갓무위키 끝까지 읽으니까 마음이 한편 편해지네;