Yahoo Design Patterns

2008.02.22 22:35

아래 사이트에 가면 Yahoo에 쓰이는
Design
적인 요소와 기능적인 요소들의 공통점을 Pattern으로 뽑아내서 그것들을 나열해 놓고 있습니다.

GoF Design Pattern은 정리를 해 놓아도 난잡하고 전달해 주기가 어려운 부분이 있었는데,
그런 부분을 보완해 줄수 있는 부분을 Yahoo Design Pattern Library에서 벤치 마킹이 가능할 듯 합니다.

 

Yahoo Design Pattern에 있는 Pattern들의 예를 보면 툴팁은 0.25이내에 떠야 한다던가,
Hover
기능이 구현될 때 주지하고 있어야 할 점과 같은것들을 다루고 있는데요.

 

모든 요소들이 공통적이고 정리가 잘 되어 있으면서, 해당 기능 관련 AJAX코드도 들어 있는데, 코드도 정교하게 잘 만들어 놨고, 쉽게 가져가서 구현할 수 있도록 해 놓았습니다.

 

http://developer.yahoo.com/ypatterns/

http://developer.yahoo.com/ypatterns/atoz.php 

 

사용자 삽입 이미지

http://developer.yahoo.com/ypatterns


아래 사이트에 가면 Implementing a Pattern library in the Real world : A Yahoo! case study 라는
논문이 있는데, Yahoo Design Pattern Library를 뽑아 내는 전체적인 과정과 내용, 적용하는 과정들이 step 형식으로 잘 나와 있습니다.

논문에 쓰인 그림 하나하나, 혹은 글의 흐름 하나하나가 GoF Design Pattern 처럼 코드의
디자인 패턴을 추출하는 과정과 유사 하군요.

 

http://leacock.com/patterns/leacock_malone_wheeler.pdf

 

 

아래 링크는 Yahoo User Interface Blog

http://www.yuiblog.com/

Posted by Intent

Pattern이라는 분야에서 GoF의 Design Pattern이 가지는 의미는 매우 귀중하다.

사용자 삽입 이미지

GoF Design Pattern

학회에서나 애기되어지고 있는 Pattern이라는 것들을 일반인 들에게 알리는 하나의 신호탄 같은 존재인 것이다.

오늘 이 중요한 Design Pattern의 두번째 Principle에 대한 몇가지 오해들을 정리해 보고자 한다.

Favor Object Composition over Class Inheritance

이 말의 의미는 원문 그대로 해석을 한다면 클래스 상속보다는 객체 조합을 선호해라 라는 애기다.

그런데 대부분의 시중에 나와 있는 책들이 상속보다는 조합을 선호하는 것으로 의미를 파악하고 애기를 하고 있다.

과연 이것이 맞는 말일까?


4년 동안 거의 패턴에 대한 책들을 본 경험을 들어 볼때, 상속이라는 것은 모든 패턴에 사용되고 있었다. 

디자인 패턴의 첫번째 원칙인 Program to an interface, not to an implementation 에서도
Program은 인터페이스 지향적으로 짜야 된다는 의미가 나와 있고,
이것은 곧 상속을 의미하는데 왜 상속보다 구현을 선호하라고 했을까?

지금 한번 패턴책을 펴보길 바란다.

어느 패턴이라도 인터페이스 상속을 받지 않은 패턴을 찾기 힘들 정도 인데
과연 상속 보다 조합을 선호하는 이분법적인 사고가 맞는 걸까?

필자는 그래서 짧은 영어 실력으로 Favor Object Compoistion over Class Inheritance를
클래스 상속을 기반으로한 객체 조합을 선호해라 라는 의미로 해석을 시도했다.

상당히 그럴싸 하지 않은가?  물론 필자의 영어 실력이 그리 뛰어난 편은 아니지만
왠지 상속을 기반으로 한 조합 이라는 의미를 부여했을때, 좀더 GoF Design Pattern에 맞게 해석된것 같이 느낄수가 있었다.

그리고 필자는 계속 스터디를 하면서 이 생각이 맞다고 결론을 내리고 있었다.
그런데 컴퓨터 분야에 유명한 번역가이신 분에게 반론이 들어왔다.

Favor Object Composition over Class Inhertance는  클래스 상속보다는 객체 조합을 선호해라 라는 의미가 맞다고.  그분이 워낙 컴퓨터 영역에서는 전문가 이시라.
여러가지 예를 들며 애기를 온라인 상으로 나누게 되었다.

그런데 대학원에서 분산 객체와 패턴을 전공으로 하고, 스터디를 2년동안 해왔는데.
과연 저말이 맞는 걸까? 상속보다 객체 조합이 훨씬 나은 거라고 말할수 있는 걸까?

왜냐면 객체지향 초기에 가장중요시 여기는 개념은 재사용성(Reusability )였다.

하지만 지금은 워낙 시스템이 방대해지고 잦은 변화가 발생하다보니 유연성(Reflexiblity)이 더 중요한 개념으로 여겨지고 있다.

유연성을 가장 쉽게 확보하는 방법이 상속을 통해서 다양한 Concrete Class를 만드는 방법인데.
객체 지향에 과연 저 말이 맞는 의미일까?

다시 생각하게 되었다.   그런데 웹 서핑중 재미난 글을 발견하게 되었다.  
 http://www.artima.com/lejava/articles/designprinciplesP.html

사용자 삽입 이미지

Eric Gamma

 바로 GoF Design Pattern의 창시자인 Erich Gamma의 최신 인터뷰 내용이었다.

  두번재 원칙인 Favor Object Composition over Class Inhertance 에서   Object Composition은 내부적으로 상속을 안 사용 한다는 의미가 아니다.

  Object Composition은 내부적으로 Interface Inheritance를 사용하고 있다는 말로 깔끔하게 설명을 했다.

  필자가 저런말을 하니 뭔가 다시 한번 Design Pattern 책을 살펴볼 필요가 있다는 생각이 들었다.

  그런데 단지 두번째 원칙 몇페이지 앞에 재미난 말을 발견했다.


 P. 17 세번째 단락. (GoF Design Pattern 원서..)

  Class inheritance defines an object's implementation
                                                 in terms of another object's implementation.  

  In short, it's a mechanism for code and representation sharing.

두번째 원칙의 Class Inheritance는 Implementation Inheritance 였던 것이다.


아마 이 두번째 원칙의 잘못된 오해 때문에, 조합이 좋다라고 단언하는 책이나 사람들이 있다.

국내 서적에서 상속보다 조합이 더 낫다라고 해석한 몇분의 지식 오류로 인해..
Composition한 부분만 너무 강조 된것이 아닌가 하고 걱정하게 되어 진다.

그럼 두번째 원칙을 다음과 같이 재정의 할수 있을 것이다.

Favor Object Composition(with Interface Inheritnace or subtyping)
                                     over Implmentation Inheritance (subclassing)

구현 상속 보다는 (인터페이스 상속-SubTyping 을 기반으로한 또는 요즘 시대에는 계약 기반의 ) 객체 조합을 선호하라는 말로 해석되어 질수 있을 것이다.

객체의 세계에서는 상속과 조합의 아름다운 결합을 추구하는 것이 패턴의 아름다운 진리인것이다.
이 글로 인해 많은 분이 Design Pattern의 두번재 원칙의 의미를 알기 바란다.

Posted by 빵수

웹 서핑중 괜찮은 자료를 발견했습니다.
Design Pattern Quick Rerference자료 인데요.  맨 아래 그림을 보시면 뭔지 아시겠죠

mcdonald 라는 분이 올려 주신 자료입니다.
이런 분들의 지식 공유에 다시금 감사를 드립니다. 연세에 맞게 글에도 Force가 느껴지는 군요.
지식 나눔의 Force가 항상 함께 하시길..

손 수 GoF Design Pattern에 나오는 패턴들을 손수 컬러링 하시고 간략히 설명해 놓으셨습니다.
시간이 되시는 분은 한글로 번역해 주시면 아주 도움이 될듯 합니다.

그리고 자료에 대해서 직접 접근하실수 있게 url을 걸어 달라고 하시네요.
자기 사이트에 대해서 많은 홍보를 하시고 싶은신가 봅니다. ^^ 
mcdonald 아저씨는 욕심쟁이~~ 우후후~~~

하나의 샘플 파일을 올려 드리죠.
Design Pattern Quick Reference에 있는 PDF, JPG, Visio 포멧의 데이터를 받으실수 있을 겁니다. ^^

풀 버젼을 받고 싶으시면 http://www.mcdonaldland.info/2007/11/28/40/ 로 접근해서 받으시길 권해드립니다.

사용자 삽입 이미지

Design Pattern Quick Reference Sample

Posted by 빵수

초등학교를 다녔을때 선생님이 국보 1호가 뭐야? 라고 물었을때 자랑스럽게 대답하던 숭례문(남대문).
한국을 대표하던 Landmark가 화마로 소실되어 많은 분이 슬퍼하고 계십니다.

사용자 삽입 이미지

화재로 읽어 버린 숭례문

우리가 만든 소프트웨어와 숭례문의 사건과 연결지어 생각해보고자 합니다.
제가 잘알고 있는 패턴 이야기로 풀어 보고자 합니다.

숭례문이 600년간 유지 되어왔던 것은 선조들부터 숭례문을 지키고 보호해 왔기 때문입니다.
끊임없이 숭례문을 지키고 감시하는 시스템이 유지되었기 때문이지요.

하지만 숭례문이 민간인에게 개방되면서,
많은 분이 기뻐했지만 결국 한명의 과오로 인해 숭례문이 불타 소실되어 버렸습니다.

아마 일반인에게 공개를 했는 만큼 보안을 신경쓰지 않아서 그랬다고 할수 있겠지만,
이런 사태는 소프트웨어의 기술적으로 보면 약간 시각이 달라집니다.

보안이라는 것은 특정 패스 카드 같은 것을 지니고 문에서 검문을 하는 것에 비유할수 있습니다.
쉽게 말해 인증서나 키와 같이 패스카드와 같은 것들이 있어야만 되는 거죠

일반인에게 다 개방을 했기 때문에 우리나라 국민이라면 다 접근을 할수 있습니다.
그러니 어떻게 보면 소프트웨어 적으로는 이러한 문제를 보안으로 풀기보다
처음부터 방어적인 프로그래밍 또는 Fault Tolerant 한 구조로 설계가 될 필요가 있습니다 .

그럼 소프트웨어가 이러한 상황이라면 어떻게 해결하는 것이 좋을까요?

해결책은 아래에 있습니다.

사용자 삽입 이미지

WatchDog



Fault Torelant 패턴 중에 WatchDog이라는 패턴이 있습니다.
이 WatchDog이라는 것은 우리가 흔히 말하는 Observer , Interceptor 패턴들과 종종 같이 사용됩니다.

WatchDog은 특정 상황을 계속 모니터링할때 사용되는 패턴으로 정책과 룰을 가지는 Agent적인 성격이 강한 패턴입니다.

 가장 쉽게 보여질수 있는 예가  Thread Pool을 관리할때 입니다.
많은 클라이언트의 접속으로 ThreadPool안에 있는 Thread가 임계점 이하로 줄어들면,
다시 Thread를 생성하라는 명령을 내리기도 합니다.
또는 시스템의 리소스를 더 생성할수 없을 경우 클라이언트의 동시 접속자수를 제한한다거나,
아니면 Message Queue에 쌓아 놀수도 있을 겁니다.

 WatchDog이라고 하니 머리속에서 번뜩하고 떠오르는 재미난 기술이 있습니다.
Microsoft의 COM+ (DCOM의 진화모델)에는 내부적으로 WatchDog을 이용해 Recycling이라는 재미난 기능을 지원합니다.  
이상하게 제가 만든 소프트웨어가 100일 정도 지나면 Thread들이 가끔 먹통이 되어서 시스템이 중지 된다고 합시다.
가장 좋은 것은 제가 Thread 의 반환하는 부분들을 잘못했기 때문인데. 도대체 어디에 있는지 찾을수 없는지 매우 난감할때가 많습니다.

우리가 정한 주기마다 Thread Pool의 Thread들을 시스템에 반환하고, 새로운 Thread를 생성하는 것인데요.
잘못 만든 정책에 의해 종종 Thread가 일정 시간이 지나면 먹통이 될 경우를 대비해 이러한 전략들을 구성해 놓았습니다.


 견고한 소프트웨어를 만들기 위해서는 로그를 남기면서 수동적으로 대처하기 보다는 로그 정보를 잘 활용해 WatchDog으로 어떻게 문제를 해결해 갈지 생각해 보는게 더 견고한 소프트웨어를 만드는 방법일 겁니다.

숭례문의 사건으로 우리의 소프트웨어도 어떤지 한번 돌아보는 시간을 가지는 것을 어떨까요?

WatchDog의 정의 (Wikipedia)
http://en.wikipedia.org/wiki/Watchdog 

관련 샘플
http://www.codeproject.com/KB/IP/watchdogmanagement.aspx 
http://www.koders.com/java/fidFB44476831876A0203C34CF6F66639231692AA7D.aspx
http://www.koders.com/ 에서 WatchDog으로 검색 해보세요.

Posted by 빵수

BLOG main image
Eva네의 소프트웨어 이야기
Devpia Eva 팀입니다. 소프트웨어 설계,패턴, 최신 이슈들을 공유하는 장이 될것입니다. by 빵수

공지사항

카테고리

전체보기 (11)
아키텍쳐 (2)
패턴 (6)
새로운 기술들 (0)
소공이야기 (0)
컬럼 및 아티클 (1)
Eva네 (2)
문래예술 (0)

글 보관함

달력

«   2018/07   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Total : 13,040
Today : 3 Yesterday : 0