디자인 패턴을 쓰시는지요?

이게 요구사항을 만족시키면, 옵저버 패턴을 안쓰면 되는거 아닌가요?

제가 C++를 자세히는 모르겠습니다만, 일방향 참조만으로 프로그램을 짤 수 있을지 모르겠네요. 또... C++가 Java보다 자유로운 정도는 지나치게 크지 않은가요?

mastercho님이 말씀하신것 처럼, 패턴이 프로그램 복잡도를 높히는데 큰 역할(?)을 하고 있는건 분명한것 같습니다. 필요할때, 필요한만큼만 쓰면되는데, 그 정도를 결정하기가 쉽지 않죠.

재즈뮤지션 찰리파커(Charlie Parker)가 어케 디자인 패턴을 알았는지^^ 다음과 같은 말을 했다고 하는군요.

Learn the patterns and then forget ‘em

객체지향적 설계에서 이런 식의 구조는 매우 일반적입니다. 가장 대표적인 경우가 도메인 객체에 대한 설계인데, 이 때는 A에서 B를 접근할 수 있는지, 혹은 반대로 B에서 A를 접근할 수 있는지, 아니면 양방향 모두 가능한지를 순수하게 분석된 비즈니스적인 요구사항에 의해 결정하는 경우가 많습니다.

예를들자면, 온라인 쇼핑몰을 구축하는데 상품과 분류의 관계에서, 화면 구성상 특정 상품을 선택했을 때 해당 상품의 분류를 알아야 하고, 반대로 특정 분류를 선택했을 때 해당 분류의 모든 상품을 뽑아야 한다면 일대다의 양방향 네비게이션으로 설계해야 합니다.

물론 이런 도메인 객체들 사이의 관계가 아니라 옵저버의 경우와 같이 순수하게 기능적인 필요에 의해 객체 참조를 주고 받는 구조도 있을 수 있습니다.

제 생각에는, 객체지향적 설계가 가능하면 실제 세계를 충실하게 반영하면 좋겠지만 어느 정도 유연성은 - 전체적인 설계의 명확성을 크게 떨어뜨리지 않는다면 허용할 수 있다고 봅니다.

그럼~

이 말씀이 정답인 거 같은데요.
일반적인 자동차-바퀴 관계에서는 옵저버패턴이 필요없지 않을까 싶기도 하지만.
좀 어거지로 적용해 보면

자동차
{
attribute:
악셀상태
브레이크상태
바퀴갯수
method:
악셀상태체크
브레이크상태체크
}

바퀴
{
attribute:
나를 매단 자동차
method:
달려라
서라
}

여기서 "나를 매단 자동차" 쓰지 않으면
main
{
내자동차 = new 자동차 (바퀴4개)
if 자동차.악셀상태=밟음
for each 바퀴:
달려라
}

쓰면

main
{
내 자동차 = new 자동차 (바퀴4개)
run thread for each 바퀴
자동차.악셀상태=밟음
}

바퀴 thread
{
if 나를 매단 자동차.악셀상태 = 밟음
달려라
}

자동차:바퀴는 1:n관계이고 자동차의 state가 변할 때 종속된 바퀴들이 자동적으로 notify 받을 수 있어야 할 필요가 있다면 옵저버를 써야겠지요.
영 어설픈 예 같은데 :(

...그냥 최고 앞에 질문만 읽어 보고 답변 다는 겁니다..

타이어가 어떤 자동차에 달려 있는지 타이어가 알 필요 있을까요...
자동차가 달리다 펑커가 나 버리면 예외 상황일 겁니다.

자동차에서 펑커 난걸 감지 한다고 한다면 예외를 받아서 잘 처리 하면 됩니다.

다르게 속도 감지를 한다면 이럴땐 타이어가 전해줄 게시판 정보만 가지고 있으면 됩니다. 자동차 까진 알 필요 없습니다.

자동차와 바퀴 보다는.. 엔진과 바퀴 정도의 결합이.. 옵저버를 쓰시는데...
더 좋은 예가 아닐까 하는데요...

거 MFC같은데 보면.. Document - View나.. 이런거 쓰잖아요...

그러니까... Data에 해당하는쪽... MVC모델로 보면... Model에 해당하는
부분은.. 자기일만 하죠... 외부와의 연결을 최소로 하구요..
그래서.. 구태여 옵저버에 대한 생각을 하시겠다면... ..
엔진하고 바퀴와의 관계정도는.. 옵저버로 쓰일수 있을 거 같다는 생각이
듭니다.. 음.. 이것도 완전하게.. 일치 하지는 않을거 같은데...

옵저버 자체가 엔진이 바퀴의 상태를 알아야 돌아갈수 있는거는 아니니까...
엔진은.. 돌고.. 바퀴는.. 엔진에 붙어 있다면 도는 거고 붙어 있지 않다면..
안도는.. 방식으로.. 물론 엔진이 바뀌면 바퀴도 바뀌어야 겠죠...
이것을 위해서 트렌스미션을 붙이고 하면.. 바퀴와 엔진은 두고 자동차만
바꿀수 있겠죠...

하지만... 옵저버 패턴이 사용되기를 원하는 목적은... 바퀴의 종류나..
트렌스 미션의 종류에 상관 없는... 혹은.. 여러개의 바퀴 여러개의
문짝이.. 엔진을 중심으로 모여 있는 구조를 만들려고 할때 사용이
됩니다..

음.. 그냥.. 생각나는 데로 적느라고.. 글이 좀 이상해 지기는 했지만...

옵저버 당하는 녀석은... (Target..??: engine 인가요.. ) 외부의 것들에
영향을 안받을수 있도록 보호 해줘야 한다는 겁니다..

그렇기 때문에.. 엔진에 영향을 받는... 바퀴가... ... 엔진에 또다시 붙어있는
핸들과 전혀 상관 없이 동작 할수 있도록요...

옵저버들은... 엔진의 상태를.. 반영만 해주죠.. 영향을 미치는 것은.. 아니니까요.. 다시 말하면... 바퀴가 빵구가 난다고 엔진이 서버리게 된다면.. 그건..
이미 옵저버 패턴으로써의 모습을 잃었다고 생각할수 있습니다..

프로젝트에... 정말 패턴을 많이 사용하고 있는데.. 적절히 잘 사용하면...
뭐 복잡도가 증가하거나 그러지는 않습니다.. 특히나 Controller나..
Facade같은것들을 잘 사용한다면... 복잡도가 일정 범위 안으로 한정되기
때문에 프로젝트 전체로 봐서 최대 복잡도..( 전체 복잡도 말고.. 부분이 가지
는 복잡도의 최고...)는... 아주 낮은 상태로 유지 할수 있는 거 같습니다..

패턴에 관련된 문답이 있길레.. 그냥 재미있다는 생각이 들어서 답변 적었습니다.

등장하는 스케일 들이 뭐죠.. .. 앞에 글들 읽기가 귀찮아서...

자동차 , 타이어 4개 , 계기판 이렇게 아닌가요...
간단합니다. 자동차는 타이어 4개와 ,계기판을 포함합니다..
그리고 타이어를 포함 할때 계기판을 타이어에 연결 시킵니다...

그러면 타이어는 계기판을 알고 속도가 얼마 인지 알려 줄수 있습니다.

만약에 타이어를 갈아 치운다 그러면 자동차의 계기판 연결을 해제 하고 헌 타이어를 빼고 새타이어를 갈아 끼운 다음에 계기판을 새타이어에 연결 하면 됩니다..

헉... 제가 언제 그런 무지막지한 말씀을 드렸나요? 자동차가 타이어를 구현하다니요 :)

아토스 --> 승용차 - -> ICar, 스노타이어 -> ITire의 관계 입니다.

이런 관계를 염두에 두고 다시 한번 위의 글을 자세히 읽어 주셨으면 좋겠습니다.

그럼~

저도 한동안 패턴에 관심이 있어 무척 흥미있게 살펴보았던 기억이 있는데, 솔직한 제 심정으로는 이게 왜 필요한 것인가 싶더군요.

이렇게 쓰면 패턴을 좋아하시는 분들의 엄청난(!) 압박에 시달릴지도 모르겠습니다만, 제 느낌을 적습니다.

기본적으로 GoF 에서 시작된 패턴들을 살펴보면 그저 소프트웨어를 구성하는 공식정도에 지나지 않는다고 생각합니다. 마치 중고등학교 시절 수학 참고서에 적혀 있던 빨간색 네모안에 적혀 있는 공식들. 이 공식만 암기한다고 무언가를 해결할 수 있는 능력이 생기는 것은 절대로 아니지요. 또 공식을 직접 증명하고 도출해보고, 이해가 되는 순간쯤이 되면 이 공식은 쓸모가 없어지는 경우도 많이 경험하셨으리라 생각합니다. 더 좋은 다른 방식으로 문제가 해결가능한 경우도 많아지지요. 찰리파커의 Learn the changes and forget about 'em 이라는 커멘트도 이와 크게 다르지 않다고 생각합니다. (아마 learn the patterns는 아닐거예요. ;-) )

바로 여기에서부터 패턴의 비극이 시작된다고 <저는> 생각합니다. 모를때는 암호같이 보이고, 알고나면 별로 쓸모가 없는 것들. 좀 더 정확히는 패턴을 알고 있는 다른 사람들과 대화하기 위한 용어의 집합체 정도들.

어느정도 다른 사람의 코드를 읽어본 경험이 있고, 소프트웨어를 많이 작성해본 개발자라면 패턴책에 있는 많은 내용들을 이미 알고 있는 것이고 많이 사용해본 것이라고 생각합니다. 그렇지 않다면 또 경력만 내세우는 쓸모없는 개발자라고도 생각합니다. 틀림없이 GoF 도 비슷한 말을 적어 놓았던 것으로 기억합니다.

하지만 역시 패턴에 등장하는 용어 몇몇을 알고 있으면 요즘에는 코드를 읽는데 많은 도움이 되는 것이 사실입니다. Factory나 Iterator 같은 놈들은 C++이나 java 심지어는 C 코드에서도 아주 많이 등장하는 단어들이지요.

패턴은 사실 경험있는 oo 프로그래머라면 익히 알고 있는 내용에 이름 붙여놓은 거에 불과 할때가 많습니다. 물론 이름이 뭐 중요하냐 싶을 수도 있지만 만약에 팀에 신참이 들어온다거나 해서 서로 다른 수준이나 분야의 개발자들이 모여서 대화할때 상호 이해가 명확한 언어를 쓰느냐 아니냐는 큰 차이를 가진다고 봅니다.

저도 패턴을 공부했다고 해서 문제를 바라볼때 패턴을 적용시킬 수 있는 능력이 생긴다고는 생각하지 않습니다. 다만 설계자가 설명할 때 알아들을 수 있는 능력은 생기지요. 이 부분은 factory와 worker를 적용해서 해결해라. 하는 것과 이 작업을 위한 interface를 따로 정의한 다음 이 작업은 이 interface를 구현한 놈들 중에 속성을 조사해서 런타임에 불러들여서 처리하도록 구현해라. 전자가 훨 간결하고 명확하다고 봅니다.

여기에 대한 명언이 있습니다. "When the only tool you have is a hammer, every problem looks like a nail". :)

패턴에만 너무 집착하다보면 모든 문제를 다 알고 있는 패턴에 끼워맞추게 되고 쓸데없는 과도한 디자인을 불러올 수 있습니다.

하지만 저는 패턴은 객체지향 언어를 사용하는 프로그래머라면 반드시 '마스터' 해야 하는 단계라고 생각합니다. 저 역시 아직 패턴을 완벽히 이해하고 활용할 수 있는 수준은 못됩니다만, 디자인 패턴은 정의 그대로 객체지향 패러다임에서 많은 수의 프로그래머들이 경험했던 공통적인 문제들에 대한 가장 일반적이고도 검증된 해법을 정리한 것입니다.

물론 개 중에는 기존의 모든 상식을 뛰어 넘는 천재적인 프로그래머가 있을 지 모르겠습니다. 하지만 일반적인 프로그래머라면 먼저 기초를 제대로 알아야 응용을 할 수 있을 것입니다.

안타깝게도 실무에서는, 패턴의 과잉 보다는 패턴은 커녕 객체지향의 기초 조차도 제대로 안잡혀진 프로그래머가 훨씬 많은 것 같습니다. 그리고 패턴은 끊임없이 변화하고 발전하고 있습니다. GoF에 소개된 패턴들을 기본으로 삼아 웹이나 분산환경 등 시대의 변화에 따라 새로 생겨난 다양한 응용패턴들을 익히는 것도 상당한 도움이 됩니다.

예를들어 자바의 경우 웹개발 관련은 http://www.theserverside.com에 가보면 지금도 여러 개발자들이 참신한 패턴을 끊임없이 제시하고 이를 검증하는 작업이 진행되고 있습니다.

그런 의미에서 저는 패턴 공부에도 상당한 의미를 두고 싶습니다.

써오신 글을 읽으면서 느낀 건데요.
인터페이스 혹은 컴포넌트를 객체와 등치되는 개념으로 생각하고 계신게 아닌지요? 그리고 C++가 C로 부터 물려받은 전처리개념의 산물로 남은 헤더파일의 꼬임과 oo의 객체간의 커플링을 같은 식으로 생각하고 계시고요. 아니시라면 죄송하지만 맞다면 이 부분을 잘 정리하고 넘어가실 필요가 있을 것 같습니다.

자동차-바퀴의 예가 계속 사용되니까 좀 도식적으로 정리를 해보면 만들고 싶은건 자동차이고 사용자는 운전자 입니다. 그리고 자동차가 자동차(사실은 바퀴를 제외한 자동차의 나머지 부분의 총합)와 바퀴로 구성되어 진다고 분석을 한거죠. 맞죠?

우선 어느 특별한 자동차에 특화된 바퀴를 만드는 것은 전혀 oo와 대치되는 일이 아닙니다. 바퀴가 고유한 속성과 그 속성을 다루는 method로 구성되고 이 method를 통해서만 사용된다면 충분히 oo스럽죠. 재사용성은 oo에서 optional한 장점이지 mandatory한 구성요소는 아닙니다.

상호참조에 의한 구현의 종속성은 oo의 여부를 결정하는 문제가 아니라 oo가 내재하고 있는 문제(커플링)로 봐야 할 것입니다. 이 커플링에 대한 해결책으로 인터페이스나 패턴이 생겨난 거죠. 무엇보다 바퀴가 자동차를 참조할 필요가 있냐 없냐가 중요한 거지 참조를 한다 안한다 혹은 그럼으로써 oo다 아니다는 중요한 문제가 아니겠죠.

하여간 바퀴가 자동차의 속성을 참조하기 위해서 특정 method를 invoke하면 이 바퀴의 구현은 자동차의 구현에 종속됩니다. 이 것을 막기 위해서 자동차의 interface를 만들고 바퀴는 이 interface를 통해서 필요한 속성을 얻어옴으로써 자동차의 구현으로 부터 독립되어집니다. 여기서 interface는 oo가 디커플링을 위해서 사용하는 메커니즘이지 oo 자체는 아닙니다. 인터페이스와 그 구현체인 컴퍼넌트가 oo의 오브젝트와 동일모듈일 경우가 많지만 그것이 컴퍼넌트가 오브젝트라는 뜻은 아니라는 거지요.

무슨 뜻이냐 하면 자동차의 인터페이스가 변경되면 바퀴의 구현이 바뀌므로 oo가 아니라는 생각을 가지고 계신거 같은데. 인터페이스는 자동차오브젝트와 바퀴오브젝트가 서로를 사용할때 커플링을 없애기 위해서 정의한 각 오브젝트와는 무관한 별도의 메커니즘이라는 겁니다. 자동차 오브젝트를 재구현 한다거나 subclassing 한다는 것과 자동차 인터페이스를 바꾼다는 것은 전혀 다른 얘기입니다. 자동차의 인터페이스는 자동차 오브젝트의 속성을 다루는 메소드가 아니라 특정 메소드 혹은 그 집합이나 속성이 외부로 노출되는 경로에 대한 명세일 뿐입니다. 이 명세를 전제로 한 바퀴오브젝트로서는 이 명세가 바뀌면 당연히 구현에 변경이 옵니다. 단 그 것은 바퀴오브젝트 또한 바뀐 명세를 사용할 필요가 있다는 뜻이죠. 바퀴로서는 전혀 바뀐 interface가 필요없다면 예전의 인터페이스를 가지고 있는 자동차오브젝트들과만 쓰여지면 되는 거죠. 이 자동차오브젝트들이 어떤 놈들이든 말이죠.

oo가 interface를 차용하는 또 하나의 이유는 잘못된 subclassing을 막고자 하는 의도도 있지요. 예를 들어 자동차에 스노우타이어를 붙인다. 이때는 타이어를 subclassing 하는 것이 자연스러우므로 문제가 안되지만 만약에 스키블레이드나 무한궤도를 붙인다고 했을때 코드 재사용성을 극대화하기 위해서 무리하게 subclassing을 하거나 매경우 class를 만들게 되면 부자연스러운 구현이거나 자동차의 코드내에 각 경우에 대한 커플링이 증가하게 되지요. 그래서 자동차 내부에서 바퀴를 바라 볼 때도 interface를 이용해서 자연스러운 구조로 디커플링을 해줄 수 있게 됩니다. 이 때 바퀴의 인터페이스는 역시 바퀴오브젝트의 속성이 아니고 바퀴오브젝트가 특정 속성을 외부로 노출하는 경로에 대한 명세일 뿐입니다. 바퀴와 스키블레이드는 전혀 다른 (클래스) 오브젝트이지만 같은 인터페이스를 구현하고 있는 컴퍼넌트가 되는 거지요.

이 때 이런 사용이 말그대로 패턴을 가지고 반복될 때 여기에 이름을 붙이고 정형화 한게 디자인 패턴이라고 생각합니다.

님께서 말씀하시는 c++ 클래스간의 상호참조의 어려움이리는 건 사실 컴파일 타임에 헤더파일이 꼬이는 문제로 c++의 전처리 메커니즘의 문제이지 패턴이 해결하고자하는 oo의 커플링과는 아무런 관계가 없는 걸로 보입니다.