What Is a Pattern?

반복되는 공통적인 문제에 대하여 가장 적절한 해결책을 제시하는 것

 

 

Benefits of Patterns(패턴의 이득)

·         디자인 문제점을 토론하기 위한 높은 레벨의 언어를 제공한다.

·         디자인 문제의 해결책을 제공한다.

·         패턴의 조합은 재사용할 수 있는 아키택쳐를 제공 한다.

 

 

디자인 패턴을 적용할 때 제일 중요한 세가지 규칙

·         구현 클래스가 아니라 인터페이스를 가지고 프로그래밍한다. à 인터페이스를 바탕으로 하는 클래스 호출

·         상속(inheritance)이 아니라 위임(delegation)을 주로 사용한다.

·         Coupling을 최소화함으로써 추후의 변화를 국부화 한다. à 어느 하나의 기능 변화가 전체 클래스 구조를 바꾸거나 혹은 많은 부분에 걸친 변화를 야기한다면 디자인이 초기부터 잘 못 되어진 거라 할 수 있다. 디자인 패턴의 기본중에 기본은 “coupling을 최소화” 함에 있다.

 

 

디자인패턴 카탈로그 기술 형식

       name(이름) : 패턴의 이름은 패턴 자체의 내용을 효과적으로 전달할 수 있어야 한다.

       Classification(종류) : 여러 개의 패턴들을 체계적으로 분류한다. (예: 생성, 구조, 행위)

       Intent(의도) : 이 패턴이 무엇을 하며 어떤 의도로 작성되었으며 무슨 문제를 해결하는 지를 설명하는 간단한 문장

       Motivation(동기) : 이 패턴이 해결해야 하는 디자인 문제와 그것을 해결하기 위해 클래스와 객체들이 어떻게 사용되는지에 대해 시나리오 형식으로 기술함

       Applicability(적용시기)

       Structure(구조) : 패턴에서 문제를 해결하기 위해 사용되는 클래스와 객체의 구조 UML 1.2 다이어그램을 통해서 일반적으로 표현한다.

       Participants(구성물) : “구조”항목에 포함된 각종 클래스와 객체의 의미와 그 책임을 설명

       Collaboration(협력관계) : 각 클래스와 객체가 자신에게 맡겨진 책임을 수행하기 위해 서로 메시지를 주고 받는 과정을 묘사함.

       Consequence(결과) : 패턴이 목적을 달성하기 위해 어떤 면을 해결하는 지를 설명하고 패턴을 적용할 때 발생할 수 있는 문제점과 패턴적용시의 효과, 시스템 상황에 따라서 변동하는 부분들을 기술

       Implementation(구현) : 패턴을 구현할 때의 고려사항과 힌트, 함정, 테크닉등과 프로그래밍 언어 별로 주의해야할 점들을 기술

       Sample Code(예제코드) : 특정 프로그래밍 언어로 패턴을 구현한 예제를 보임

       Known Uses(알려진 사례) : 실제로 사용되는 시스템에서 발견되는 패턴의 예제를 기술

       Related Patterns(관련 패턴) : 본 패턴과 유사하거나 밀접하게 관련된 다른 패턴을 기술

저자: 김대곤



이 패턴을 설명하기 전에 MVC 모델을 먼저 살펴보자. MVC 모델은 조금은 거창하게 알려져 있는 듯하다. 거의 그런 경우가 드물지만, 몇 년 전 필자가 본 누군가의 이력서에는 자신의 강점을 프로젝트에 MVC모델을 적용한다는 것이라고 적혀 있는 걸 보았다. 필자가 보기에 MVC 모델을 적용한다는 것은 달리기를 한다는 말과 같아 보인다. 필자도 달리기를 한다. 그러나 잘 하지는 못한다. 국민학교(초등학교)때부터 체육은 언제나 주저하게 되는 분야였다. 달리기를 잘하는 것과 달리기를 하는 것은 다른 문제이다.

MVC 모델에서 MVC는 각각 Model, View, Control를 말한다. Model은 데이터 또는 기본 기능을 말하고, View는 유저 인터페이스를 말한다. 이 두가지는 시스템 개발에 있어서 없어서는 안되는 부분이며, 누가 개발을 하더라도 반드시 있기 마련이다. MVC 모델은 C 모델이라고 불러도 상관없을 만큼 한마디로 말해서 Control이라는 레이어 계층을 두자는 것이다. Graphical User Interface를 사용할 때, Model 계층과 View 계층 사이에 Control 계층을 만들어서 사용하자는 것이다. 왜 그렇게 해야 하는가? 여기에는 몇가지 가정이 담겨 있다.

두 계층 사이에 필수적이지 않은 다른 계층을 두는 이유는 간단하게 말해서 두 계층이 직접적으로 Coupling되는 것을 피하려고 하기 때문이다. 즉, Control 계층은 Model 계층과 View 계층의 high Coupling을 막아준다. Model 계층과 View 계층의 high coupling이 좋지 않은 이유는 Model과 View의 생명주기가 다르기 때문이다. 일반적으로 Model 계층의 생명주기가 길며, 변경이 드물게 일어난다고 여겨진다. 예를 들어, 물건을 파는 웹 사이트에서 사이버 매장을 새 단장하는 경우를 생각해 보자. 일반적으로 View만 바뀌지 Model은 바뀌지 않는다. 같은 기능을 가진 시스템에서 사용자에 따라서 다른 View가 존재할 수도 있다. 또는 웹사이트에서도 보고, PDA에서도 보는 경우도 같은 Model이 서로 다른 View로 표현되는 예라고 할 수 있다. 직접적인 Coupling은 Model과 View를 같이 바뀌도록 만든다. 이것을 Control 계층이 막아준다. 그럼 View가 바뀌면 Control이 바뀌어야 하는 것이면 마찬가지 아닌가 하는 의문이 생긴다. Control 계층의 로직은 매우 간단한다. 아니 간단하게 설계해야 한다. 적어도 Model를 바꾸는 것보다 훨씬 쉽게. Control 계층은 단지 Coordinator에 불과해야 하기 때문이다.

MVC 모델은 Layered Style이고 Layered Style에서는 아래 Layer가 상위 Layer를 사용하는 것을 권장하지 않는다. A 계층이 B 계층을 사용하게 되면, A 계층은 B 계층에 종속된다. 즉, B 계층이 없으면 A 계층은 자신의 역할을 수행하지 못하는 것이다. B 계층은 A 계층이 없어도 문제가 없다. 이러한 의존관계를 Usage dependency 라고 부른다. Layered Style에서 상위 계층은 하위 계층에 대해 Usage dependency가 있다. 하위 계층이 더 생명주기가 길며, 변경되는 일이 적어야 한다. 그런데 하위 계층이 상위 계층에 있는 기능을 사용하면 하위 계층이 상위 계층에 종속되어 버린다. 만약, MVC 모델에서 Model이 View의 기능을 사용해야 하는 경우에 Model이 View에 종속되는 것을 어떻게 막을 것인가?

이것이 Observer 패턴을 사용하게 되는 중에 하나이다. 이제 Observer 패턴에 대해서 살펴보자. GoF의 디자인 패턴에는 Observer 패턴의 목적을 이렇게 정의하고 있다. "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and update automatically." "한 객체의 상태가 바뀔 때 다른 객체들에게 그 사실을 알려주고 자동적으로 업데이트 되도록 하고자 한다면 이 패턴을 쓰시오" 정도 될 것이다. 좀 걸리는 단어는 one-to-many dependency다. 이제 하나씩 살펴보도록 하자.

한 객체의 상태에 변화가 생기면, 그 객체의 상태에 관심있는 객체들에게 알려주는 방식이다. 객체에게 무엇인가를 알려주는 방법은 객체의 메소드를 통해서 이다. 관심 있는 객체의 메소드를 호출해주면 된다. 하지만 객체의 메소드를 사용하면, 이 객체에 대해 usage dependency가 생기게 된다. 즉, coupling이 높아진다. 이 패턴은 특정한 알려주는 방식을 제안하고 있다.

이 패턴이 어떻게 작동되는지 살펴보자. 예제 파일[Download]을 실행해 보자. 아래의 두 화면이 보인다. Input data 에 데이터를 입력하면 Observer 화면에 나타나도록 되어 있다.

"Subject.java"에 있는 Vector 데이타가 바뀔 때 자동적으로 바뀐 내용을 보여주려고 한다. Subject 객체가 Observer객체의 내용을 바꾸기 위해서는 Observer객체의 메소드를 호출해야 하고, 메소드를 호출하기 위해서는 그 객체의 Reference가 필요하다.

Subject 객체의 addObserver라는 메소드를 통해 Observer는 자신의 Reference를 제공하고, Subject는 Observer 객체(MyFrame.java)의 update(Vector v) 메소드를 통해 화면을 바꾸어 준다. 별 무리 없이 작동하고 있다. 문제점은? MyFrame 클래스를 삭제해 보면 알게 된다. Subject 클래스가 더 이상 컴파일 되지 않는다. 이유는 간단하다. 자신의 Observer였던 MyFrame 클래스를 소스안에 포함하고 있었기 때문이다. 만약, 객체의 상태에 관심을 가지고 있는 객체가 오직 하나이고, 변경될 소지가 적다면, 위와 같이 코딩해도 별 문제는 없을 것이다. 하지만 Observer가 한 개가 아니라 20개 정도 되면 20 개나 되는 타입의 클래스를 포함하고 있게 된다. 그 중에 updata(Vector v)라는 메소드를 가지고 있지 않은 클래스라도 있으면 그건 바로 에러가 된다.

이러한 문제를 해결하는 방법은 Subject가 각 Observer들의 클래스 타입 대신 인터페이스를 사용하고, 이 인터페이스는 자신을 구현하는 클래스들에게 update(Vector v)라는 메소드를 구현하도록 강제한다. [Download]

코드를 자세히 살펴보면, 이 Observer 패턴과 자바의 이벤트 처리가 같음을 알 수 있다. 리스너(ActionListener)를 만들고, 리스너를 Subject(JButton)에 등록하고 JButton의 상태가 변하면 ActionListener로 강제된 actionPerformed 메소드가 호출된다. 이 패턴도 Observer 인터페이스를 구현하는 객체를 만들고, 만든 객체를 Subject에 등록하고, Subject 객체는 자신의 상태가 바뀌면, 인터페이스에 정의된 메소드를 호출한다. 즉 Observer 패턴은 이벤트 시스템을 구현할 때 사용된다. 이벤트 시스템의 구현은 Observer 패턴이 주는 또 하나의 강점이다.

하지만 기본은 전혀 바뀌지 않았다. 객체에게 무엇인가를 알려주는 방식은 메소드이고 메소드의 호출을 위해서는 객체의 Reference가 필요하는 것. 조금 다른 방식일 뿐 이 두가지 작업은 패턴을 적용해도 피할 수 없는 것이다. 즉, 패턴은 어떤 문제들을 교묘히 피해가는, 평소에는 잘 생각나지 않는 방법을 알려주고 있다. 그래서 패턴을 언제 사용하는가에 대한 이해는 외우지 않고 있으면 잘 생각나지 않고, 사용하지 않으면 이해되지 않는 측면이 있다. 패턴은 처음 적용해 볼 때 가장 어렵다. 한 번 하고 나면 생각만큼 어렵지는 않다.

필자의 패턴 설명은 전체적으로 모든 내용을 다루고 있진 않다. 일반적으로 Subject는 attach(Obsever obs), detach(Observer obs), notifyAll() 이라는 메소드를 가지고 있다. 하지만 detach 메소드는 다루지 않았다. 인터페이스가 강제하는 메소드도 여러 형태가 될 수 있으며, 그 메소드에 내용이 전달되지 않고 Subject의 다른 메소드를 호출함으로 Subject의 상태를 가져오기도 한다. 자세한 사항은 Design Pattern 책을 참고하기 바란다. Jstorm(www.jstorm.pe.kr)에서도 Design Pattern에 관련된 자료들을 찾을 수 있으리라 생각된다.

 

출처 : http://network.hanbitbook.co.kr

간지란 말만 빼고 싶은데 구찮아서..ㅡ_ㅡ;;

요새는 이런 스킬을 쓰나부네... 나이먹은게 느껴진다..ㅠㅠ

[30대가 바라보는 20대가 취업 못하는 이유]

 

Re: 김형태님께 카운셀링 의뢰합니다.

안녕하십니까.
입춘이 지났건만 아직도 키보드를 치고 있는 제 손꾸락은 차갑기만 합니다.
김형태님께서는 몸건강하시겠지요.

다름이 아니오라 요즘 사회적 이슈인 '이태백' 의 일원인 본인의 넋두리를 들어주십사,
더불어 형태님의 생각을 들어보고 싶어 이렇게 얼어붙은 손꾸락을 움직이고 있습니다.

저는 지방대 디자인학과 졸업예정이고 다른 이태백 일원들과 마찬가지로 여러군데 이력서를 넣고 있는 와중입니다.
연락오는 곳은 별로 없고 무언가 불안하면서도 편안한(?) 생활이 이어지고 있습니다.

이곳저곳 이력서를 넣고 있지만 솔직히 제가 무엇을 하고픈지 알수가 없습니다.
원래의 전공인 제품디자인을 하고 싶다가도 디스플레이를 하고 싶기도 하고 영화공부를 하고 싶기도 합니다.

제품디자인을 하자 라고 하면 평생 영화공부는 커녕 영화찍는 것도 구경하지 못할 듯하고
영화공부를 하자고 하면 학교다닐때 했던 과제들의 즐거움이 떠오릅니다.

일단은 먹고 살아야하니 직장을 다녀야 할듯해서 계속 이력서는 넣고 있지만 만약 회사에 다닌다면 영화공부는 할 수 없을 것 같습니다.
완전히 영화에 미쳤다든가 비범하다든가 하는 인간극장에 나올법한 사람과는 거리가 멀기 때문에 회사에 다니면서 다른 것을 병행하기란 힘이 들 것 같습니다.

아 정말 모르겠습니다.

올해 후반에 있을 영화교육기관(?) 시험을 보고싶은데 모르겠습니다.
그때까지 매달려야할까 아니면 직장을 다니면서 틈틈히 해야할까. 그렇다고 영화라는 것이 내 평생 직업으로서 가치가 있는 것일까.
힘들고 배고픈 그 직업에 대해 환상을 가지고 있는 것은 아닐까나. 또한 4년동안 했던 디자인은. 대체.

기대를 걸고 있는 부모님의 얼굴이 떠오릅니다. 부모님께서는 당연히 제가 하고 싶은 것을 하도록 놔두시겠지만
그래도 안정된 직장생활을 하면서 부모님께 조금이라도 호강을 시켜드리고 싶습니다.
하지마는 그 '안정된'직장생활의 끝에는 나의 꿈이 있을 것 같진 않습니다.

백수가 되어 이것저것 가릴때는 아니지만 신중하고 싶습니다.
섣불리 조금 앞만 바라보고 결정했다가는 나중에 후회 할 일들이 이만저만이 아닐것 같습니다.
사실 이 글을 쓰면서 생각하기를 일단은 취직을 하고 회사에 다니면서 영어공부를 하고,
영화쪽이나 디자인 쪽으로 유학을 가리라는 생각을 했습니다.

but 회사를 몇년 다니면 유학을 갈 수 있을까,
아니면 그 영화교육기관에는 들어갈수 있을까. 라는 생각이 부메랑처럼 또 따라옵니다.

횡설수설 앞뒤 안맞는 소릴 해댔습니다.  하고 싶은 일이 많다는 것이 행복한 고민일까요. 
어쩌면 진짜 하고 싶은 것이 없어서 하는 소릴지도 모르겠습니다.

조금 더 많이 사신 형태님께서는 지금 제가 어떤 선택을 해야 형태님의 나이가 되어서는
때 나 정말 잘했어 라는 말을 할 수 있을까요. 조언 부탁드립니다.

읽어주셔서 감사합니다.(앗 이것은 자기소개서 끝에 오는 말)
 

===========================================================

[답변]

 

당신은, 요즘 20대 청년실업자의 전형입니다.
20대가 왜 그렇게 취직하기가 어려운 줄 아십니까?
사람들은 불경기라서 그렇다고 말하지만, 사실은 그 반대입니다.

20대들이 정확히 하고 싶은 일이 없고, 확실하게 할 줄 아는 것이 없고,
겁은 많아서 실패는 무진장 두려워 하고, 무엇이든 보상이 확실하게 보장되지 않으면 절대 시작도 하지 않으며
눈은 높아서 자기가 하는 일도, 주변의 현실들도 모두 못마땅하고, 시시껄렁하고,
옛날 사람들처럼 고생고생하면서 자수성가하는 것은 할 자신도 없고 하고 싶지도 않고,
어떡하면 편하고 안정된 직장을 얻어 돈을 벌수 있을까만 궁리합니다.

20대가 그런 식이니까 사회가 무기력해지고 경제가 침체되어 불경기가 오는 것이죠.

그럼 세상은 어떤지 이야기 해드리죠.

취업문이 좁다고들 난리지만, 사실 모든 회사에서는 새로운 인재가 없어서 난리입니다.

세상은 자꾸 변해가고 경제구조도 바뀌어가니까 새로운 젊은 인재들이 회사에 들어와서 젊은 피를 수혈해줘야 하는데
이력서를 디미는 젊은이들은 하나같이 개성도 없고 창의력도 없고 일에 대한 열정도 없이 그저 돈만 바라보고 온 사람들입니다.

회사입장에서 볼 때 그런 사람들은 조금만 더 나은 봉급을 주는 직장이 나타나면
미련없이 회사를 그만둘 사람들로 보이고,
또 그들이 기대하는 젊은 혈기와 창의력도 없이 누구나 학원 좀 다니면 딸 수 있는 뻔한 자격증만 잔뜩 가지고 오죠.
그래서 요즘 회사들은 신입사원 최우선 기준이 '충성도'랍니다.

이말인즉슨, 너희는 그냥 시키는 일이나 로보트처럼 한다면 일자릴 주겠다.는 뜻이죠.
개성과 창의력은 포기하고 잡부나 시키겠다는 것입니다.

지금 20대들은 자신들이 신세대이고 새로운 감각을 가지고 있다고 믿겠지만,
사실, 회사나 산업현장에서 당장 필요한 능력은 그런 겉멋이나 추상적인 감각이 아닙니다.
그리고 직장은 돈을 벌자고 다니는 것이 당연하겠지만, 당신처럼 하고싶은 일은 따로 있으면서
단지 돈만 바라보고 원하지도 않는 직장에 입사원서를 내는 것을 회사중역들은 모두 알고 있습니다.

그러니 500명 1000명이 와도 뽑을 사람이 없는 것이죠.
이를테면 사랑하는 사람이 따로있는 사람과 결혼을 하겠습니까?
그런 사람은 세상 어디에서도 원하지 않습니다.

20대가 취직을 못하는 이유는, 바로, 특별히 할줄 아는 일도, 특별히 하고 싶은 일도 없기 때문입니다. 
모든 어른들은 그 사실을 면접때 눈빛만 봐도 다 알아봅니다.
그리고, 나약한 의지박약에 굴리는 잔대가리가 문제입니다.

당신이 쓴 글을 보십시오.
이것도 하고 싶고 저것도 하고 싶은데, 저걸 하면 배고플 거 같고, 이걸하면 잘 된다는 보장은 없고
돈도 벌고싶으니 취직도 하고싶은데 직장은 재미없을 것 같고....

그 와중에 대학원엘 갈까 유학을 갈까... 편안한 학생신분만 연장하려고 하고, 대체 뭘 하고싶다는 것입니까.
당신의 진로문제를 짧게 정리해보면, '하고싶은 건 많지만 고생해가면서 까지 꼭 해야할 건 아니고,
그냥 먹고살게 안정된 직장에 들어가면 좋겠는데 그게 쉽지도 않거니와 또 시시할 거 같아요' 입니다.
 
그런 사람을 받아주는 회사는 세상에 하나도 없습니다.

그리고 그런 사람이 만든 영화가 감동스러울 수 없고, 그런 사람이 기획한 디자인이 아름다울 리 없습니다.

그래서, 오늘날의 20대들이 그렇게 많은 자격증과 명문대 졸업장과 수백장의 입사원서를 들고 뛰어 다녀도 취직이 안되는 이유이고,
나라의 심장부가 그 모양이니 이 나라의 경제가 침체되고, 장기 불황이 시작되는 이유인 것입니다.

 

이렇게 이야기하면, 당신들은 잘못된 교육탓으로 돌립니다.
물론 맞는 이야기입니다. 동정표 한장!
하지만, 교육이 엉망이었던 것은 예나 지금이나 마찬가지였습니다.

 

그래도 당신들의 부모나 선배들은 더 발전적인 삶을 살았다는 것을 보고 배워야합니다.
훨씬 열악한 환경 안에서 훨씬 일찍 철이 들고, 나라를 발전 시켰으며 그 와중에 나름대로의 문화생활도 영위했습니다.
남탓, 시대탓, 환경 탓하는 것만큼 구제불능의 바보는 없습니다.

참고로, 아시아 모든 국가 중에서 우리나라가 청소년의 어른에 대한 공경심 조사에서 꼴찌를 차지했다는 사실을 기억하십시오.
어른을, 선배를, 과거를 존경하지 않는 젊은이는 원대한 꿈을 가질 수 없습니다.
꿈과 희망이란, "나도 저 누군가처럼 될테다." 하는 동경에서 시작되는 것이거든요.
당신들의 큰 바위 얼굴은 누구입니까? 그런 게 있습니까? 오직, 자기자신과 돈에 대한 동경만 있지않은가요?

섣불리 결정했다가 나중에 후회할까 두렵다고요?

왜 해보지도 않은 일을 후회할 걱정부터 합니까? 보지도 않은 영화를 재미없을까봐 포기하고,
가보지도 않은 여행지에 볼 게 없을까봐 안 가기로 하고, 저 요리가 맛이 없을까봐 안 먹고...
사는 건 대체 뭘까요?

 

당신이 어떤 인간인지 당신은 알고 있습니까?

정말 영화를 얼마나 좋아하는지, 얼마나 잘 만들 수 있는지, 디자인은 또 얼마나 훌륭하게 할 지,
회사를 다니면 얼마나 뛰어난 업무능력이 발휘될 지, 당신이 어떻게 해보지도 않고 침대위에서 그 짧은 인생경험으로 알 수 있겠습니까.
양다리에 삼발이에 문어발로 온갖 일에 맘을 다 걸쳐놓고 실제로 하는 일은, 해본 일은 하나도 없으니 불안할 수 밖에요.

'하고싶은 일이 많다는 행복한 고민'이요? 웃기는 자위입니다.
'내가 뭘 할줄 알고 뭘 하면 행복해 하는 인간인지 이 나이 먹도록 하나도 모르겠어요.'로 들리는 헛똑똑이의 넋두리로밖에 안들립니다.
좀더 신랄하게 당신의 심리를 파헤쳐보자면,
영화를 하고 싶다는 것은 현실도피성 희망입니다. 솔직히 디자인도 최고로 잘할 자신이 없는것이죠. 자신의 전공쪽으로도 별로 희망이 보이지 않으니까,
'사실 나는 디자인보다 영화에 관심이 훨씬 많다. 그래서 늦게라도 영화공부를 다시 한다.' 라는 상황에 대한 알리바이를 미리 준비해두려는 것이죠.
취직이 계속 안되는 상황에도 대비하고 있습니다. 여기저기 입사원서 던지다가 어디 좋은데 운 좋게 취직되면, 당신은 이러겠죠.

"먹고 살아야하고, 부모님께도 효도하려고 내가 진짜 좋아하는 디자인과 영화를 포기했어." 그냥 나약한 생활인일 뿐인데 어느새 순교자로 승화되는거죠.
그 좋은 머리를 그런 자기합리화에 쓰기에 바쁘니 뭘 하나 똑부러지게 실천하겠습니까.

 

내 말이, 억울합니까?
그럼 실천해 보십시오.

 

우선, 근무조건이 좀 열악한 직장을 선택해서 취직을 하세요. 그럼 금방 취직됩니다.
봉급도 좀 만족스럽지 못하겠지만, 자기 한입 먹고 살만큼은 줄 겁니다.
그리고 20년 계획으로 영화에 대한 공부를 시작하세요.
용돈을 쪼개서 모으고 모아서 캠코더를 사고... 컴퓨터를 사서 편집장비를 마련하고 (왠만한 PC로 다 가능합니다)
책을 사서 읽고, 주말에 영화 관련 포럼에 찾아 다니고, 틈틈히 시나리오를 쓰고,
휴가때는 비디오 영화를 만들어 보고, 이 모든 것은 직장 다니면서 할 수 있습니다.

게다가 20년 계획으로 꾸준히 하면, 습작이 꽤 될거고, 시나리오도 몇편 나올 겁니다.
디자인 공부한 건 영화에 고스란히 활용될 거니까 아깝다고 생각하지 말고요, 그렇게 해서 40대가 되면,
당신은 어느새 다니던 직장에서 직위도 올라가있어서 월급도 꽤 되고 어느새 안정된 직장이 되어있으며,
영화 감독으로 데뷔하기에 경쟁자가 없으리 만큼 탄탄한 준비를 가진 40대 신예 영화감독이 되어있을 것입니다.

 

그럼 바로 성공이냐? 아니죠.
입봉하고 나서 한 10년 현장에서 시행착오도 겪고, 기대도 받았다가 실패도 했다가 오르락내리락하면서 진정한 실력을 쌓습니다.
앗 어느새 50대가 되었네요.
여러분들은 이정도되면 인생 쫑났다고 생각할 겁니다.
그러나 나이먹고 알고보면, 세상은 어른들의 세계입니다.
그렇게 30년 줄기차게 정진해서 60가까이에 걸작을 하나 남길 수 있다면,
당신은 최고로 멋진 인생을 산 것입니다. 인생은 결과보다 과정에 더 많은 가치가 있으며,
결과까지도 좋다면 더 바랄 나위가 없는 것이거든요.

 

'인생은 60부터' 란 말에는 삶의 커다란 진실이 있습니다.

그러나, 당신은 그렇게 하지 않을 것입니다. 내 말을 못 믿어서가 아니라,
후줄근한 직장에 다니면서 20~30년이나 투자할 만큼 영화를 그 정도로 갈구한 것도 아니거든요.
이 글을 읽는 동안에도, 저렇게 할 수 없는 피치못할 적당한 구실을 찾느라 머리를 쓸 뿐이죠.
벌써 몇가지 변명을 만들어 냈을지도 모르죠.

 

결국 자기 인생에 변명을 만드느라 젊은 날을 허비하고 있다면 참 암울할 뿐입니다.
당신들, 정말, 왜들, 그렇게도, 경험으로 진리를 찾기를 두려워한답니까?
한 개인의 카운셀링에 대해 어느새 '당신들'이라는 복수형이 되고, 이렇게 정성들여 장황하게 답변을 올린 것은,
정말이지, 청년실업의 주인공들인 20대들 모두에게 전하는 메시지인 까닭입니다.

===================================================
나도 딱 질문자 입장이었는데... 나이를 먹어가니..쩝...

Factory Method 패턴
저자: 김대곤  출처 : 한빛네트워크(http://network.hanbitbook.co.kr)

필자는 지난 번 기사(GRASP 패턴)에서 Singleton 패턴이 Factory Method 패턴을 구현하고 있다고 했는데, 그것은 잘못된 표현이다. 실제로 Singleton 패턴은 Factory Method 패턴을 구현하고 있지 않다. 이런 착각은 필자가 패턴을 이해할 때, 그것을 지나치게 단순화(Abstraction)시켜서 이해하기 때문이다. 필자에겐 Object의 생성을 담당하는 메소드가 있으면 모두 Factory Method 패턴을 구현하고 있는 것처럼 보이고, 항상 그렇다는 착각에 빠진다.

본 기사는 앞에 언급되었던 몇가지 주제들을 설명함으로서 Factory Method 패턴이 직면하는 상황이 왜 발생하는지를 제시할 것이다. Factory Method 패턴 자체는 별로 어려워 보이지 않는다. 그런데 좀처럼 패턴을 사용해야 하는 상황을 만나지 못하는 것이 이 패턴을 이해하는데 가장 큰 걸림돌이 아닐까 생각한다. 그러므로 패턴 자체에 대한 설명은 독자의 몫으로 남겨두고자 한다.

Abstraction

필자는 패턴을 단순화(또는 추상화 Abstraction)시켜서 이해한다고 말했다. Gang of Four의 Design Patterns에는 "Consequences", "Implementation"라는 소제목들이 등장한다. 하지만 필자는 거의 읽어본 적이 없고, 관심도 없다. 그러므로 필자에게 패턴이라는 단어와 "Consequences"나 "Implementation"이라는 단어와 연관되지 않는다. 이렇듯이 관심사항이 아닌 것을 제거해버리는 것을 추상화(Abstraction)이라고 할 수 있다.

Factory Method 패턴이 Object가 생성되어야 하는 시점은 알고 있으나 어떤 Object가 생성되어야 하는지 알 수 없을 때, 객체의 생성을 Subclass에 위임하는 방식으로 문제를 해결할 수 있다고 말하고 있다. 첫 번째 질문은 왜 이런 상황에 직면하게 되었는가이다. 어떻게 이런 일이 발생할 수 있는가? 그것은 여러 종류의 객체를 추상화(Abstraction)시켜서 사용했기 때문이다.

게임의 예를 들어보자. 이 게임은 병사와 탱크를 가지고 전투를 하는 게임이고, 병사와 탱크를 만들기 위해서 병사를 만들어 내는 막사와 탱크를 만들어 내는 공장이 있어야 된다. 게임의 기능은 "생성", "공격", "이동"이 있다. 생성의 기능을 자세히 살펴보자. 게임상에 존재하는 어떤 물체를 선택하고 "생성" 버튼을 눌렀다고 가정하자. 먼저 선택한 물체가 생성이라는 기능을 가지고 있는 객체인지를 확인하고, 막사이면 병사를 공장이면 탱크를 만들어야 한다. 만약, 실제 객체(막사와 공장)을 사용하였다고 가정하자. 그런데 비행기를 만드는 새로운 공장이 생기면 생성 기능은 수정되어야 한다. 선택한 객체가 새로운 공장인지를 체크해야 하고, 새로운 공장이면 비행기를 만들어야 하기 때문이다. "생성"이라는 기능의 입장에서는 그게 막사인지, 공장인지, 아니면 새로운 공장인지는 관심의 대상이 아니다. "생성" 기능의 입장에선 오직 선택한 객체가 "생성"이라는 기능을 가지고 있는가만 알면 된다. 실제로는 존재하진 않지만 생성이라는 기능을 가진 것들을 Factory라는 개념으로 추상화하여 사용하면, 빈번한 수정과 High Coupling을 피할 수 있다. 객체의 종류에 따라 행동양식이 바뀌는 경우, 조건문을 사용하지 말고 다형성(Polymorphism)를 사용하라는 GRASP 패턴의 "Polymorphism" 원칙을 적용하여 Interface를 만들어서 생성 기능안에서는 Factory Interface만 사용하고 실제 객체들은 Factory Interface 타입의 변수 안에서 모두 숨겨진다. 새로운 공장이 만들 때 Factory Interface만 구현하면 "생성"버튼의 코드는 전혀 수정될 필요가 없다.

"생성" 기능 버튼을 사용자가 클릭하면, 객체를 생성해야 한다. 시점은 알지만 어떤 객체가 생성될 것인지는 선택되는 객체에 따라서 다르다. 그러면 당연히 Factory 객체는 객체의 생성을 담당하는 메소드(병사, 탱크, 비행기 등을 만들어야 함으로)를 가지고 있어야 한다. 이것이 Factory Method 패턴이 직면하는 상황인 것이다. 사실 이 문제는 객체의 생성 뿐 아니라 일반적인 행동(메소드)도 마찬가지이다. "이동" 기능에 대해서 생각해보라.

객체 생성을 (생성자가 아닌) 메소드를 통해서 하고자 하는 이유

실제 코드 예제를 보기 전에 객체를 생성자가 아닌 메소드를 통해서 생성하려고 하는 이유에 대해서 살펴보자. 메소드를 통해서 생성한다는 것은 Singleton 패턴에 나오는 Singleton 클래스 또는 Static 메소드를 통한 자기 자신 타입의 객체 생성이 아닌 경우에는 객체를 자기 자신의 메소드가 아닌 다른 객체의 메소드 안에서 생성한다는 의미이다. GRASP 패턴에 나오는 Creator 패턴에서 설명했듯이 이런 경우 컨텍스에서 제공받아야 하거나 제약사항들을 체크할 수 있다. 어떤 객체가 Interface를 구현한 객체의 경우, Interface를 쓴 이유는 실제 객체를 숨기기 위해서 한 작업인데, 생성자를 통해서 하면 실제 객체가 드러나 목표하는 효과를 볼 수 없게 되기 때문이다.

너무나 유명하고, 흔한 예제

필자가 아는 선배는 글을 쓰거나 프리젠테이션을 할 때는 항상 예제를 제공하는 것이 기본적인 예의이지 원칙이라고 했다. 설명을 하면 어려운 것도 예제를 보면 쉽게 이해가 되기 때문이겠지만 사실 이해하기 쉬운 예제를 제공하는 것은 쉬운 일이 아니다. Factory Method 패턴은 너무 유명하고 흔해서 검색엔진으로 검색하면 금방 찾을 수 있다. 솔직히 말하면, 필자도 이 예제를 그런 방식으로 구했다. 1분 전에.

import java.sql.*;                                



public class JDBCExample {

  private static String url    = "";

  private static String user   = "";

  private static String passwd = "";



  public static void main(String args[]) {

    try {

      Class.forName("oracle.jdbc.driver.OracleDriver");

       

      Connection connection = DriverManager.getConnection(url,user,passwd);

      Statement statement = connection.createStatement(); 

      ResultSet resultSet = statement.executeQuery("Select to_char(sysdate) from dual");



      while (resultSet.next()) 

      {

        System.out.println("It is " + resultSet.getString(1));  

      }



      resultSet.close();

      statement.close();

      connection.close();            

    } catch (Exception e) {

    } finally {

    }

  }

}

몇 가지이 수정이 가해지지 않으면, 이 예제는 실행되지는 않을 것이다. 그러나 Factory Method 패턴을 사용한 클래스가 무려 2개나 된다. 그것도 연결해서 사용했다. Connection 객체는 createStatement() 메소드를 통해서 Statement 객체를 생성하고 Statement 객체는 executeQuery() 메소드를 통해서 ResultSet 객체를 생성하고 있다. Connection, Statement는 모두 Interface이다. 만약 실제 객체를 사용했다면 위의 코드는 다음과 비슷한 모습이 될 것이다.

public class OracleJDBC {

  

  private static String   url    = "";

  private static String   user   = "";

  private static String   passwd = "";



  public static void main(String args[]) {

    try {

      Class.forName("oracle.jdbc.driver.OracleDriver");

       

      OracleConnection connection  = new OracleConnection(url,user,passwd);

      OracleStatement  statement   = new OracleStatement(); 

      OracleResultSet  resultSet   = statement.executeQuery("Select to_char(sysdate) from dual");



      while (resultSet.next()) 

      {

        System.out.println("It is " + resultSet.getString(1));  

      }



      resultSet.close();

      statement.close();

      connection.close();            

    } catch (Exception e) {

    } finally {

    }

  }

}

위 코드는 실행되거나 컴파일이 되거나 하지는 않는다. 실제 오라클을 사용할 경우 쓰이는 객체들이지만 이렇게 코딩하는 사람은 없다. 만약 오라클 안쓰면 다 고쳐야 되는데 누가 이렇게 쓰겠는가? 위의 작업을 하는 사람들에겐 실제 무슨 객체가 쓰이는가는 관심사항이 아니다. 단지 어느 곳에 저장되어 있는 데이터를 읽어서 가져오는 것이 주요 목표인 것이다. JDBC는 각 데이터베이스들을 추상화했지만 더 높은 추상화를 적용한 JDO(Java Data Object)도 있다. JDO는 Persistence에 대한 추상화를 시도하고 있다.

결어

그럼 추상화(Abstraction)를 어떻게 할 것인가? 이런 문제는 아무도 설명해 주지 않는다. 필자도 누구에게서 추상화의 원리나 관련된 강의를 받은 적이 없다. 필자가 항상 염두에 두는 생각이 있다면 "내가 필요로 하는 최소한의 것만 받아들이겠다"는 자세이다. 누가 나에게 무언가를 요청한다면 "네가 좀 알아서 해 주면 안돼?"라고 말하는 자세 말이다.(실제로 이렇게 살면 맞아 죽겠지만 말이다.) 그렇게 해서 남은 최소한 것을 Interface로 정의해서 사용하자.

필자가 쓰고 있는 패턴에 관한 기사도 Design Pattern를 설명한다기 보다는 Design Pattern이라는 주제에 대해 버리고 버려서 남은, 비슷해 보이지만 전혀 다른 내용이 아닐까 생각한다. 필자는 상속을 좋아하지 않는다. 그래서 SubClass, SuperClass와 같은 용어보다는 Interface라는 용어를 많이 사용한다. 그러나 상속에 대해서도 적용될 수 있음을 밝혀두는 바이다.

PSP... 지를까 말까 벌써 1달 넘게 고민중...ㅡ_ㅡ;;

어흑

PS2 지르고 나서 2년이 지나도록 총 구동시간이 10시간이 안되는데

PSP도 그꼴 날까봐 지름신의 강림을 힘들게 힘들게 막고있다..

어흑 추석때 버스 5시간도 넘게 탈텐데... 이 생각만 하믄

지름신의 압박이! ㅠ0ㅠ 힘들구낭...

구글토크를 꼭 써보고 싶어서 힘들게 힘들게

암흑의 루트를 통해서 가입했다.

그.런.데.

깜빡 생각을 안했던...



구글토크에 로그인도 했는데... 친구가 없다!!!

어흑..ㅠ0ㅠ 왜 그걸 생각 못했을까...

나 바본가 부다..ㅠㅠ

sesfinkl@GMail.com <<= 누가 Add Friend 좀 해달라고!

Immutable Pattern
JLab 편집실 blueduck (최성원)

한객체에 동시접속 오버헤드를 줄이고 레퍼런스를 같은 객체와 공유하여 객체의 견고함(robustness)을 증가시켜 주는 패턴입니다. 객체가 생성된 후에 객체 상태 정보가 빠귀는것을 허락하지 않으므로써 객체의 견고함(robustness)을 이룰수 있습니다. 또한, Immutable 패턴은 한 객체를 공유하는 멀티 쓰레드의 실행을 동기화하는 요구를 피합니다. 내용 여러 객체들에 의해서 사용되어지는 객체의 상태 정보 변경을 동기화하고, 상태정보가 전파되는 것을 막기 위해서 공유되는 객체를 immutable객체로 만들 수 있습니다. immutable객체는 객체가 생긴 후에는 어떠한 상태변화도 허락하지 않습니다. 이는 상태정보를 변경하는 메소드를 포함하지 않음으로써 구현할 수 있습니다. 멤벼 변수 값을 수정하는 set 메소드가 없어야 하는 것이겠지요.

immutable 클래스는 상태변화를 필요로 하지 않으며 여러 다른 객체들에 의해서 사용되어지는 클래스의 경우에 유용하며, 멀티쓰레드에 의해서 공유되는 객체의 상태를 일관성있게 유지해야하는 경유에 유용합니다. 멀티쓰레드에 의해서 공유되는 경우에는 멀티쓰레드의 실행을 동기화할 필요가 없으므로 동기화에 따르는 오버헤드를 줄일수 있으며, 객체의 robustness(견고함,강건함)를 증가시킬 수 있습니다.

immutable클래스를 구현하기 위한 요구사항으로는

　

* 생성자들을 제외하고 클래스의 멤버 변수 값을 수정하는 메소드(setter 메소드 등)가 없어야 합니다.
* 새로운 상태 정보를 생성하는 메소드는 새로운 인스턴스에 저장해서 그 인스턴스를 반환하도록 해야합니다.

일반적으로 immutable패턴을 read only object라고도 합니다. 예를 들면, 어떤 클래스(Foo)는 getter 메소드와 setter메소드를 모두 가집니다. 그리고 여러 일반 사용자에게 foo객체에 상태 정보를 변경하지 못하도록 제한하기 위해서 ReadOnlyIF를 만들 수 있습니다. ReadOnlyFooIF 인터페이스는 Foo클래스와 동일한 getter메소드들만 가집니다. 그래서 일반 사용자가 ReadOnlyIF를 통해서 간접적으로 Foo객체에 접근하게 함으로써 immutable 패턴의 robustness를 얻을 수 있게 되는 것입니다.

* 모든 인스턴스 변수는 불변해야합니다. 즉, 상수 혹은 "blank" 상수이어야 합니다. 그래야지만, 결국 공개(public)될수 있습니다.
* setter 즉 set 메소드가 없어야 하고 getter 즉 get 메소드만 있어야 합니다.
* 메소드에 의해 상태정보가 바뀐다면 새로운 인스턴스에 저장해서 그 인스턴스를 반환하도록 해야합니다.
* 이러한 이유들 때문에, Immutable 패턴은 멀티쓰레드의 사용을 유용하게 합니다. JAVA API USAGE Java API의 String클래스는 immutable 클래스의 대표적인 예입니다. String 클래스에서는 자신을 나타내는 연속적인 Character들은 객체가 생성될 때 정해지며 변하지 않습니다. String 클래스의 toLowerCase(), subString() 등의 메소드들은 자신의 상태정보(즉, 연속적인 Character들의 값)를 변경하지 않고 새로운 String 객체를 생성해서 반환합니다.



* 코드 예제

또 하나의 예로 2차원 공간의 위치를 나타내는 Position객체를 생각해 보겠습니다. Position에는 좌표의 위치를 나타내는 x와 y가 멤버변수로 존재합니다. 그리고 x와 y의 offset으로 새로운 Position객체를 생성하는 메소드를 가집니다. 이 메소드는 자신의 x값, y값을 변경하지 않고, 새로운 객체를 생성해서 반환하도록 합니다. Position클래스의 소스코드는 다음과 같습니다.



public class Position {
private int x;
private int y;

public Position(int x, int y) {
this.x = x;
this.y = y;
}
public int getX(){
return this.x;
}
public int getY() {
return this.y;
}
public Position offset(int xoffset, int yoffset) {
return new Position(x + xoffset, y + yoffset);
}
}
　



관련된 패턴 Single Threaded Execution(Concurrency Pattern)

이전 기사(Singleton 패턴)을 쓰면서, 다음에 다루어야 할 주제는 Observer 패턴이 아니면, Factory Method 패턴이라고 생각했다. GUI의 구조를 보면 Observer 패턴을 설명할 때 재사용할 수 있을 것 같은 생각이 들었고, 패턴의 분류에 따르면 Singleton 패턴은 Creational 패턴에 속하고, 또한 그 간단한 패턴에서도 다른 패턴을 하나 사용하고 있는데, 그것이 Factory Method 패턴이다.

어느 패턴을 먼저 설명하더라도 약간의 준비 작업을 필요하다. Factory Method 패턴을 설명하려고 하면, Creational 패턴들이 전체적으로 다루고 있는 두가지 문제에 대한 설명이 필요하다. Creational 패턴을 사용하는 목적은 주로 두가지라고 할 수 있는데, 하나는 시스템이 사용하는 Concrete 클래스가 무엇인지 감추는 것이고, 또 다른 하나는 객체가 어떻게 생성되며, 구성되는지 감추는 것이다.[Note : Concrete 클래스란 직접적으로 객체 생성이 가능한 클래스를 말한다. 즉 인터페이스나 Abstract 클래스가 아닌 클래스이다.]

이 두가지가 주요한 목표라면, 어떻게 왜 그 목표를 설정하게 되었는지를 이해하면 Creational 패턴들에 대한 전반을 이해하고, 각 패턴들을 이해하는데 도움이 될 것이다.

이 기사에서는 GRASP Pattern을 설명할 것이다. GRASP 패턴은 General Responsibility Assignment Software Patterns의 축약어이다. Object-Oriented 디자인의 핵심 문제는 각 객체에 역할(또는 책임)을 부여하는 것이다. GRASP Pattern은 역할 부여의 원칙들을 말하고 있다. 일반적으로 디자인 패턴이라고 불리우는 것들처럼 구체적인 구조는 없지만, 각 디자인 패턴들은 GRASP 패턴이 제시하는 철학를 각 상황에서 구체적으로 구현할 것이라 볼 수 있다. GRASP 패턴을 설명하면, Creational 패턴들이 왜 앞에서 설명한 두 가지를 목표로 하고 있는지를 이해하는데 도움이 되리라 생각된다.

GRASP 패턴은 아홉 가지로 구성되어 있다. 사실 각 패턴들이 너무 간단해서 싱거울 정도이다.

1. Information Expert: 역할을 수행할 수 있는 정보를 가지고 있는 객체에 역할을 부여하자. 단순해 보이는 이 원칙은 객체지향의 기본 원리 중에 하나이다. 객체는 데이터와 처리로직이 함께 묶여 있는 것이고, 자신의 데이터를 감추고자 하면 오직 자기 자신의 처리 로직에서만 데이터를 처리하고, 외부에는 그 기능(역할)만을 제공해야 하기 때문이다.


2. Creator: 객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여하자. A 객체와 B 객체의 관계의 관계가 다음 중 하나라면 A의 생성을 B의 역할로 부여하라.
- B 객체가 A 객체를 포함하고 있다.
- B 객체가 A 객체의 정보를 기록하고 있다.
- A 객체가 B 객체의 일부이다.
- B 객체가 A 객체를 긴밀하게 사용하고 있다.
- B 객체가 A 객체의 생성에 필요한 정보를 가지고 있다.


3. Controller: 시스템 이벤트(사용자의 요청)를 처리할 객체를 만들자. 시스템, 서브시스템으로 들어오는 외부 요청을 처리하는 객체를 만들어 사용하라. 만약 어떤 서브시스템안에 있는 각 객체의 기능을 사용할 때, 직접적으로 각 객체에 접근하게 된다면 서브시스템과 외부간의 Coupling이 증가되고, 서브시스템의 어떤 객체를 수정할 경우, 외부에 주는 충격이 크게 된다. 서브시스템을 사용하는 입장에서 보면, 이 Controller 객체만 알고 있으면 되므로 사용하기 쉽다.


4. Low Coupling: 객체들간, 서브 시스템들간의 상호의존도가 낮게 역할을 부여하자. Object-Oriented 시스템은 각 객체들과 그들 간의 상호작용을 통하여 요구사항을 충족시키는 것을 기본으로 한다. 그러므로, 각 객체들 사이에 Coupling이 존재하지 않을 수는 없다. 이 패턴은 요구사항은 충족시키면서도 각 객체들, 각 서브시스템 간의 Coupling를 낮은 수준으로 유지하는 방향으로 디자인하라고 말하고 있다. Low Coupling은 각 객체, 서브시스템의 재 사용성을 높이고, 시스템 관리에 편하게 한다.


5. High Cohesion: 각 객체가 밀접하게 연관된 역할들만 가지도록 역할을 부여하자. 이 패턴은 Low Coupling 패턴과 동전의 양면을 이루는 것으로, 한 객체, 한 서브시스템이 자기 자신이 부여받은 역할만을 수행하도록 짜임새 있게 구성되어 있다면, 자신이 부여 받은 역할을 충족시키기 위해 다른 객체나 시스템을 참조하는 일이 적을 것이고, 그것이 곧 Low Coupling이기 때문이다.


6. Polymorphism: 객체의 종류에 따라 행동양식이 바뀐다면, Polymorphism 기능을 사용하자. Object-Oriented 시스템은 상속과 Polymorphism(다형성)을 지원한다. 만약 객체의 종류에 따라 행동이 바뀐다면 객체의 종류를 체크하는 조건문을 사용하지 말고, Object-Oriented 시스템의 Polymorphism 기능을 사용하라.


7. Pure Fabrication: Information Expert 패턴을 적용하면 Low Coupling과 High Cohesion의 원칙이 깨어진다면, 기능적인 역할을 별도로 한 곳으로 모으자. 데이터베이스 정보를 저장하거나, 로그 정보를 기록하는 역할에 대해 생각해 보자. 각 정보는 각각의 객체들이 가지고 있을 것이다. 이 때 Information Expert 패턴을 적용하면, 각 객체들이 정보를 저장하고, 로그를 기록하는 역할을 담당해야 하지만, 실제로 그렇게 사용하는 사람들은 없다. 이것은 그 기능들이 시스템 전반적으로 사용되고 있기 때문에 각 객체에 그 기능을 부여하는 것은 각 객체들이 특정 데이터베이스에 종속을 가져오거나, 로그을 기록하는 매커니즘을 수정할 경우, 모든 객체를 수정해야 하는 결과를 가져온다. 즉 Low Coupling의 원칙이 깨어지게 된다. 이럴 경우에는 공통적인 기능을 제공하는 역할을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.


8. Indirection: 두 객체 사이의 직접적인 Coupling을 피하고 싶으면, 그 사이에 다른 객체를 사용하라. 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다. 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.


9. Protected Variations: 변경될 여지가 있는 곳에 안정된 인터페이스를 정의해서 사용하자. JDBC에 대해서 생각해 보자. JDBC는 일련의 인터페이스들로 구성되어 있으며, 각 데이터베이스 벤더들이 인터페이스를 구현한 Concrete 클래스를 제공하고 있다. 데이터베이스 기능을 사용하는 시스템의 입장에선 각 벤더들이 구현방식을 바꾸었을 때, 자신의 코드를 수정하고 싶지 않을 것이다. 그래서 Driver를 로딩하는 코드를 제외하고는 모두 인터페이스를 사용함으로서 데이터베이스의 변경시에도 Driver 로딩만 바꾸어 주면 되도록 데이터베이스 관련 작업이 필요한 곳에는 안정된 JDBC 인터페이스를 사용한 것이다.

지금까지 GRASP 패턴에 대해서 살펴보았다. 다시 처음 주제로 돌아와서, Creational Pattern에서 실제로 사용되는 Concrete 클래스를 숨기려고 하는 이유는 Low Coupling를 지원하려고 하기 때문이며, 변경될 여지가 있는 것들(Protected Variations)을 사용하는 시스템에 충격을 감소시키기 원하기 때문이다. Concrete 클래스를 숨겼지만, 결국 그 객체를 사용하기 해야 한다. 그러면 어떻게 사용할 것인가? 일반적으로 인터페이스 타입의 변수에 저장해서 사용한다. 각 Concrete 클래스를 대표하는 안정된 인터페이스를 만들 수 있다면, 그럴 경우에만 Creational Pattern들은 자신의 역량을 최대할 발휘할 수 있다. 두 번째로 왜 객체의 생성과 구성을 감추려고 하는가? 어떤 객체를 사용하기 위해서는 두 가지 작업이 필요하다. 먼저 객체를 생성해야 한다. 생성되어 있다면, 객체에 대한 Reference를 얻어와야 한다. 두 번째는 그 객체에 정의된, 사용하고자 하는 메소드을 알아야 한다. 객체 사용시 Low Coupling을 원한다면, 두 가지 작업을 해야 한다. 객체 생성을 숨기고, 메소드를 (주로 인터페이스를 이용하여) 자신이 원하는 수준으로 Abstract시킨다. Creational Pattern은 전자를 Structural Pattern들과 Behavioral Pattern들은 후자를 한다.

다음 기사에서는 Creational Pattern 중에 하나인 Factory Method 패턴을 살펴볼 것이다.