POSA, 패턴 시스템

패턴 시스템에 대하여 마인드 맵으로 정리해보았다.

패턴 분류와 관련하여 GoF 디자인 패턴의 목적(purpose)과 범위(scope) 분류에 대한 부정적 서술이 눈에 띈다. 게다가 이 글을 작성한 사람은 GoF 패턴 집필진 중 한명인 Richard Helm 이다. 아울러 패턴 분류를 위한 분류 스키마를 제안하고 있는데 꽤 괜찮아보인다.(도입해야지~^^)

	아키텍처 패턴	디자인 패턴	이디엄
혼돈에서 질서로 from mud to structure	Layers Pipes and Filters Blackboard	Interpreter
분산 시스템 distributed system	Broker Pipes and Filters Microkernel
상호작용 시스템 interactive system	MVC PVC
적응 시스템 adaptable system	Microkernel Reflection
생성 creation		Abstract Factory Prototype Builder	Singleton Factory Method
구조 분해 structural decomposition		Whole-Part Composite
작업 조직화 organization of work		Master-Slave Chain of Responsibility  Command Mediator
액세스 제어 access control		Proxy Facade Iterator
서비스 변경 service variation		Bridge Strategy State	Template Method
서비스 확장 service extension		Decorator Visitor
관리 management		Command Processor View Handler Memento
적응 adaptation		Adapter
통신 communication		Publisher-Subscriber Forwarder-Receiver Client-Dispatcher-Server
리소스 핸들링 resource handling		Flyweight	Counted Pointer

(Italic BOLD: GoF 의 디자인패턴)

지금까지 프로젝트를 진행해오며~ 1차적인 개념 설계 후, 2차적인 물리 설계에 들어갈 무렵 패턴을 선정하곤 했는데... 이때 산출되는 클래스 다이어그램에 색깔별로 패턴을 분류(2012/02/13 - [프로그래밍/OOP] - Proactor with IOCP)하여 팀원간 의견 교류를 해왔다. 사실, 의견 교류라기 보다는... 강의(패턴에 기반한 개발 방식에 익숙한 프로그래머들이 드물어서...) 비슷하게 진행되는 경우가 대부분이었다. 아무튼 그럴바에야 좀 더 체계적인 패턴 시스템 서술 방식으로 교화(?)하는게 좋지 않을까?^^ 앞으로 상기 분류 스키마를 활용해볼 생각이다.(울 팀원들은 몰모트.. ㅋㅋㅋ)

물론, 상기 분류 스키마는 GoF 의 디자인 패턴과 POSA 1 의 패턴들을 정리한 것이라 POSA 2 ~ 5 까지에 해당하는 내용은 차츰 담아나가야할 것이다. 끝으로 "패턴 시스템의 발전" 부분은 기억해둘만하다. 왜냐하면 패턴 시스템을 언어(쉽게말해 개발자간 커뮤니케이션 수단이지 않은가?)로 볼 수 있는데 각각의 패턴은 단어에 속하기 때문이다. 보통 언어는 언중에 의해 발전하거나 도태되는데 패턴 시스템도 마찬가지다. 그렇다면 패턴 시스템에서 언중은 무엇이고 어떻게 발전하고 도태되는가 생각해볼 수 있겠다. 뭐 나같은 사람은 아직 말을 배워야하는 아기(Baby)일 뿐이고~ 언중의 역할은 PLoP(Pattern Languages of Programs) conference 같은 곳에서 이뤄진다고 보면 되겠다. 올해는 http://www.hillside.net/plop/2012/ 이렇게 되겠다.

PLoP 와 관련하여 좋은 포스팅 글~
http://arload.wordpress.com/2009/08/31/plop-writers_workshop-demo/ 
http://arload.wordpress.com/2009/09/01/plop-fly-on-the-wall/ 

개인적으로 자기만의 패턴이 어쩌구~하시는 분들을 간혹 뵙곤하는데, 대부분은 기존의 패턴이거나 혹은 변종이거나 혹은 도퇴되어 쓰이지 않는 패턴 중 하나이다. 자신의 패턴을 인정받고 공식적으로 쓰이길 원한다면 PLoP 의 저자 워크샵(writer's workshop)에 참여할 것을 강력히 추천하는 바이다. 물론, 그 전에 기존 패턴 공부부터 열심히 하셔야겠지만~ ^^

아쉬운 건 국내 아키텍처들이 좀 더 쉽게 접근할 수 있는 컨퍼런스가 있으면 좋겠다는 생각... 하지만 국내 개발자 혹은 아키텍처들의 영향력이란 국제 기준으로 보았을 때 눈꼽에도 속하지 않기 때문에 당분간은 어쩔 수 없어 보인다. 언젠가 콩글리쉬가 당당히 영어의 한 파트로 인정받는 날을 기대해보며~