디자인 패턴및 설계에 관해....
토론 토의에 제가 올렸던 주제인데 그림이 올라가질 않아서
여기서 다시 그림을 첨부해 토론을 계속 하겠습니다
우선 인터페이스를 활용하는 방식은 :ICar와 ITire를 잘 정의하고 문서화 합니다. 그리고 ICar를 상속받아 덤프트럭부터 경차까지 구체적인 구현을 합니다. 그리고 ITire를 상속받아 일반 타이어부터 스노우 타이어 등등을 구현합니다. 물론 ITire에는 타이어의 규격을 읽어오는 메소드가 정의되어야 합니다.
이 때 ITire와 ICar만 바뀌지 않는다면 - 사실 자동차와 바퀴의 관계가 혁신적으로 바뀌지 않는 한 이런 일은 흔하지 않습니다 - 개별적인 자동차와 타이어는 서로의 구현을 신경쓸 필요가 전혀 없습니다. 이 부분이 바로 커플링을 줄일 수 있다는 뜻입니다.
< 위에 2다 상속이라고 표현은 되어 있지만 밑에 그림처럼이해햇습니다>
이런 말씀을 하셨는데 , 그림을 보시면 아시겠지만
이건 상호간에 참조를 하지 않습니다
단방향으로 ATos가 SnowTire을 참조 할뿐이죠
제가 의문이 드는건
그림에 보듯이 바퀴 인터페이스가 자동차 인터페이스를 모르는 것과
비유가 되지 않은가 싶네요
그리고 메세지 인터페이스에 대해 말씀을 드리면
메세지는 일종의 프로토콜이라고 볼수 있지 않겠습니까?
ICar와 ITire의 인터페이스를 둘다 모르더라도
프로토콜만 맞추면 , 메세지를 보내는 int 값만 하나만으로도 서로간에
대화가 되는 그런것으로 볼수 있지 않나 싶습니다
예를 들면 윈도우GUI에서 실시하는 메세징 방식이죠
그리고 바퀴에서 메세지를 받을 경우 자동차로 콜백 메세지를 보낸다는
개념으로 말씀을 해주셨는데
이것도 상당히 애매한 개념입니다
이건 웹에서 모든게 콜백방식으로 이루어다보니 간단히 이해가 되지만
쓰레드중심으로 동작하는 어플리케이션 설계에는 적당하지 않은거 같습니다
어플리케이션은 (일반적으로) 단일 쓰레드에서 작동하며
메세지를 일단 받는곳은 어플리케이션 자체입니다
자동차 바퀴로 보자면 , 바퀴에서에서 문제가 발생해서 이벤트를 자동차로
전해준다기보단 자동차가 바퀴를 감시대기 하고 있다가[폴링이라기보단
인터럽트 방식이라 해야 옮은거 같습니다]
해당 이벤트가 발생하면 자동차가 바퀴에다가 메세지를 보내고 그 결과값을 얻는 방식이라 볼수 있지 않나 싶습니다
[바퀴가 직접 메세지를 받고 보낸다면 바퀴에도 쓰레드를 달고
작동시키는거와 같지 않을까요?]
모든 중심은 자동차에서 이루어지기때문에 바퀴는 결국 자동차를 알 필요가 없는거가 되는것이죠,또한 자동차 내에서 이루어지는 인터페이스클래스들도 자동차를 통해 컨트롤 되는 개념이 명확하지 않은지요?
이런식으로 단방향 구조로 어느정도 깊게 짜더라도 그렇게 헷갈리지 않게 되지만 , 상호 참조를 할경우 C++에서 include의 문제와 클래스를
하나의 컴포넌트로 보지 못하고 자기를 제어하는 클래스를 알아야하는
종속적인 클래스가 되는게 아닌가 싶습니다
또한 클래스간에 여러 요소가 참조하며 엉키면 정말 C++에서는 컴파일하기조차
짜증이 나지 않나 싶습니다
| 첨부 | 파일 크기 |
|---|---|
 Car 설계.JPG | 8.4 KB |
Re: 디자인 패턴및 설계에 관해....
맞습니다. 위에서 인용하신 부분은 상호 참조가 올바른 설계인지가 아니라 메시징을 통한 클래스간 호출의 문제점에 대해 이야기하면서 나온 부분입니다.
예를들어 웹브라우저를 설계한다면 당연히 웹서버의 인스턴스를 참조해 직접 호출하는 것이 아니라 잘 정의된 HTTP 프로토콜에 의해 통신하는 방식을 따를 수 밖에 없습니다. 전세계 웹서버와 웹브라우저를 같은 언어로 만들게 아니라면 말이죠 :)
반면 일반적인 설계에서 모든 클래스 간의 통신을 그런 방식으로 처리한다면 몇가지 문제점이 생깁니다.
(1) HTTP 규약 같이 잘 정의된 표준이 없기 때문에 프로그래머가 자의적으로 정의한 코드와 메시지 번호들로 인해 프로그램이 번잡해지기 쉽습니다.
(2) 마찬가지 이유로 메시징을 처리하는 쪽에서는 상대 클래스의 상세 구현을 알아야 합니다.
(3) 이런 방식으로는 객체 지향적 설계의 인터페이스 중심의 설계나 상속관계, 형검사 등등의 개념이 무시됩니다. 객체지향이 만능은 아니지만 객체지향적 패러다임을 받아들이면서 이를 무시하는 방향으로 설계를 한다면 좀 문제가 있다고 봅니다.
이 경우는 양쪽 다 유효한 설계라고 생각합니다. 문제는 과연 자동차 바퀴가 자동차에 대한 참조를 가지고 있는 것이 더 중요한지, 아니면 일반적인 옵저버 패턴을 구현했을 때의 편이성이 더 우선인지에 대한 가치 판단의 문제라고 봅니다.
C/C++은 잘 몰라서 어떻게 구현이 어려워 지는지 잘 모르겠습니다만, 말씀 하신대로 자바에서는 매우 일반적인 형태의 구현이고 특별히 코드가 복잡해진다거나 하지 않습니다.
단, 말씀 드렸듯이 문제가 되는 클래스간의 커플링은 단순히 참조를 가지고 있고 아니고에 따라 판단하는 것이 아니라, 참조하는 클래스의 구체적 구현의 변화에 따라 영향을 받는지 안받는지입니다. 즉, 설사 타이어가 자동차에 대한 참조를 가지고 있다 해고 Atoz가 아닌 ICar로 받는 한 큰 문제는 없다는 뜻입니다.
물론 이는 원론적인 이야기고, 위의 타이어-자동차의 예제에서는 제가 생각해도 타이어가 자신의 상태를 자동차에 알려야 하는 경우가 딱히 생각나지 않는 군요... 제 생각에는 실제 비즈니스 적으로 이런 상태를 알려줄 필요가 있는데 개념적으로 단방향 참조가 되는 구체적 예제를 찾아서 제시해 주실 수 있다면 좀 더 재미있는 토론이 되지 않을까 싶습니다.
그럼~
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...