학부생시절… (^^) 가끔 프로그래밍을 곧잘 하는 것 처럼 보이는 사람이 패턴을 사용하여 자신의 소프트웨어를 설명하는 것을 볼 수가 있었다. 그럴때보면 가끔, 자신의 상황을 패턴에 너무 억지로 맞춰넣는 것 같은 생각이 들 때가 있다. 세상의 모든 s/w 컴포넌트가 GOF 의 패턴만으로 해결되지는 않는다. (그랬다면 그 많은 패턴책이 나오지도 않았겠죠..)

나는 소프트웨어나 객체지향 프로그래밍의 전문가는 아니지만, 패턴에 대해서는 한가지 철학이 있다. 내 철학은, 객체지향을 알고 싶으면 반드시 디자인 패턴을 공부하라는 것이다. 그리고 디자인패턴을 공부할때는 열심히 다 이해하고 GOF의 질문들을 스스로 풀어보려고 노력한뒤에, 패턴을 몽땅 잊어버려야한다. 그리고 나서는 리팩토링을 보는게 좋을거라 생각한다. 그 뒤엔 또다시 리팩토링을 몽땅 잊어버려야한다. (이렇게 쓰니 무슨 무술 전수하는것 같군 -_-;;;)

디자인 패턴에서 전달하는 메시지는 아래의 GRASP Pattern 이라는 용어로 설명한 그 것 정도면 충분하다고 본다. 그 이상은 패턴이 항상 100% 맞아 떨어지지는 않으므로 패턴책을 아주 매우 가끔 펴보면서 객체지향적으로 짜면 된다고 본다. 리팩토링도 마찬가지이다. 리팩토링은 디자인 패턴이 왜 그렇게 짜여져있는지에 대한 근본원리를 전수한다. 그 근본원리 몇개를 느끼고 나서는 몽땅 잊어버려야한다. 리팩토링 기법의 이름외우는건 삽질이다..

물론 모든 사람이 디자인 패턴을 공부하지는 않으므로 s/w를 설명할 때 자신이 사용한 패턴을 설명하는 건 좋다. 하지만, 패턴을 썼기 때문에 유연한 구조라던가 혹은 힘들게 적당한 패턴을 찾아내 적용했다는 이야기를 들을 때는 나로선 정말 반감이 생긴다. (저번학기 ㅇㅇ수업에서도 그렇게 설명하는 학생이 있었다..) 힘들게 패턴을 찾을 필요없이 객체지향방식으로 짜고, 객체지향적이지 못한 부분을 객체지향적으로 더 바꿔주던가 혹은 머리 싸잡아 매고 이리저리 그림을 그려보면 답이 나오게 된다. GOF가 무슨 만능열쇠도아니고, 그것에만 짜맞추려고 매달려있으면 정말 자신의 경험과 능력의 한계를 고백하는것이나 다름없다.

주위의 OOP가 뭔지 모르겠다는 친구들에게 종종 패턴을 보라고 말한다. 그러면 친구들은 그 책을 정말 봐야하냐고 묻는다. 그럼 봐야한다고 설명해준다. 하지만, 시간이 지나도 그사람들은 절대 패턴책을 안펴본다. 제발 패턴책 한번만 봐달라… 거기엔 OOP에 대해 궁금해하던 질문의 답들이 다 들어있다.

———————————-
원저자:김대곤
출처:http://network.hanbitbook.co.kr/view_news.htm?serial=716

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

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

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

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

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

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

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

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

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

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

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