예전에.. 거 모시기 대기업 다닐때 내 선임에 의해서 .. 억지로 월급 받아먹기와, 시간 때우기와, 레포트를 겸한 책읽기가.. Applying UML and Patterns였다.. 이것이 한국말로 번역돼어 나온것이 UML과 패턴의 적용, 이거가.. 참.. 좋은 책이다..
그런대.. 이책에 나와있는 패턴의 내용들은.. GoF의 Design Pattern의 내용도 있지만.. GRASP이라는 것이 있다.. 내용들이.. 좀 평이하기는 하지만.. 예전기억에.. 너무나도 중요했던, 쉽지만.. 중요한.. 그러니까.. 기본이라는 느낌이 들었던 것들이다.
우리가 객체 지향이라는 것을 이야기를 하면서 기본적으로 넘어야 할 선이라는 것이 있어 보인다.. 뭐라.. 말하기는 좀 명확하지 않지만.. 객체라는 것을 찾아 내고, 그 객체들의 책임과 권한을 명확히 해가면서 프로그램을 작성하는 것이 객체지향의 모습 아닌가 한다. ..
이 책의 GRASP패턴에 관한 이야기는.. 객체들에게 Responsibility를 어떻게 할당할 것인가에 중점을 맞추고 있다. 저.. Responsibility를 그냥 영어로 적어 놓은것은.. 그냥 그 느낌으로 받아들이라는.. 나는.. 대충.. Role 비슷한 것으로 받아들인다. 연극으로 말하자면.. 배역이라는 느낌.. 연극을 프로그램으로 빗대어 이야기를 하자면.. 각자가 가진 역할만 있을뿐이지.. 나레이션이 연극 자체는 아니라는 말이다. 가끔 나레이션이 나올수는 있지만.. 예전에 우리가 절차적인 프로그래밍에서 보았던.. 나레이션에 의한 나레이션을 통한 스토리 전개는 아니라는 말이다. 연극은 쉽게 말해 소설과는 다르다는 말이다. 각각의 배역에는.. 각각의 성격이 있고, 각각의 대사와 행동이 있다. 막이 올라가면.. 각각의 배역의 역할에 따라 연극이 진행돼고 그것을 통해 관객은 스토리를 이해한다.. .. 소프트웨어 개발을 그런식으로 가져가는 것이 객체지향적이라는 말이다.
GRASP(General Responsibility Assignemnt Software Pattern) 이란다.. 음.. 해석하자면. 소프트웨어에서 객체간에 역할을 분담하는 패턴이란다.. ..
슬슬보자.. 첫번째로 나오는 것이.. Information Expert전문가 패턴이라는 이야기 이다.. 하지만 여기서 우리는 어떤것이 전문가인지 잘 봐야 한다. 시간이 언제나 없다는 말은 언제든지 시간을 만들수 있다는 말이고, 모든이의 연인이라는 말은 그 누구의 연인도 아니다 라는 말도 있다. 여기서 전문가라는 말은.. "잘 알고 있다," 만을 이야기 하지는 않는다.. 연이이 돼기 위해서는 누구 한사람 만의 짝이어야 한다는 말이다. 하나만 알자. 자기의 역할에 대해서는.. 자신이 다 책임을 지고, 너무 한개의 객체가 여러가지를 찝쩍거리지 말라는 말이다.
맡은 바나 잘 해라. 가 이 패턴의 기본 적인 정신이다. 절대로 만물박사는 전문가가 될수 없다.
연극에서 아무리 잘 하는 배우가 있어도 모든 배역의 대사를 혼자 다 말해서는 안된다. 그건 연극이 아니라, 소설 낭송회 이다. 이이야기는.. 기본적으로, 정보 은닉(Information Hiding), Data Encapsulation, Polymophism모두와 관련된 이야기 이다. 결국 자기가 전문가 라면, 자기의 정보는 자기가 가지고 있고, 다른 사람은 볼 필요가 없기 때문에 외부로의 정보를 가리라는 말이 된다. 모든이가 자기의 정보에 대한 전문가라면.. 자신이 전문가일 필요가 없다. 또한 다형성은.. 음.. 자기가 알아서 하니까.. 위에서는 명령만 내려라 이다. .. (이거가.. 말이 좋기 때문에 엮으려고 따지면 다 엮인다.) ..
두번째.. Creator패턴이다.. 어떤 객체가 다른 객체를 생성할 책임을 지는가이다. .. Main에서 모든 객체를 다 생성해서.. 한쪽으로 다 밀어 넣어 줘서는 안된다는 말이다. 결국 .. 그러면. Main은.. 너무 많은 책임을 떠 맡게 된다. 객체를 생성한다는 것은 그 객체에 대한 모든 것을 알고 있다는 말도 된다.( 실제로 C++의 경우 모든것을 알아야 생성된다. ) 생성된 이후에는.. 그 객체의 Interface만 필요할뿐 객체의 모든것을 다 알필요는 없다. 따라서. 처음 나왔던 전문가 만큼이나.. 또 다른것이.. 그 객체를 잘 알아야 한다. 물론 자기가 자기를 만들어서 주면 된다. 하지만.. 그런 방법 말고도 객체의 생성에 대한 책임을 질수 있는 혹은 져야 하는 객체가 어떤것인지에 대해서 나온다.
1. B가 A로 구성돼어 있을때.
2. B가 A를 가지고 있을때.. (1번과 2번은 미묘하게 다르다.. Aggregate, Have의 차이정도)
3. B가 A의 Data를 기록할때.
4. B가 A를 아주 가깝게 사용할때
5. A의 생성 Data를 B가 가지고 있을때..
등등의 경우에 B가 A의 Creator가 될수 있다. 정말.. 아주 가까운 경우들이다.
왜 이렇게 까지 하는지에 대한 이유는.. 다음에 좀더 이야기를 해본다.. (다음번에가 아니라.. 다음의 패턴이나 그다음 패턴을 이야기 한 후에..)
Low Coupling ..
가급적이면.. 많은 것들과 관계를 맺지말라(불륜이다.)는 말이다. Low Coupling이라는 말은.. 복잡도 라는 말과 연관이 많이 Coupling이 많이 늘어나면.. 복잡도는.. 필연적으로 늘어날수 밖에 없다. 게다가.. 응집도(Cohesion)는 떨어질수 밖에 없다. 쉽게 말하면.. 아는 녀석들끼리 할수 있는 것은 아는 녀석들끼리 다 해 쳐먹자는 말이다. 해 쳐먹고 있는 것들 괜히 딴넘들한테 알려서 일 복잡하게 만들지 말고, 해 쳐먹을 수 있는 넘들 그리고.. 그것에 관련된 녀석들 끼리만 잘 알고 있자는 말이다. 이러한 노력들로 인해.. 소프트웨어 개발이 구획화 될수 있는 것이다. 쉽게 말하면.. 왼손이 한일을 오른손이 모르게 하자 인데.. 이러면.. 왼손쪽의 수행 방법이나 기타의 것들이 바뀐다 해도 오른 손의 입장에서는 하등 상관이 없다는 말이다. 이것이 상당히 중요하다.. 가리려면 다가리고 보여 줄꺼면 다 보여주고,(All or nothing)하라는 말이다.
어차피 알넘은 다 알아도 돼고, 몰라야 하는 넘한테는.. 끝까지 쌩까야 한다. 이도 저도 아니라면.. 한가지 일을 해야 할때.. 눈치봐야 할 넘들이 너무 많아 진다. 따라서, 변경등 유지 보수의 비용이 기하급수적으로 늘어 날수도 있다는 말이다.
High Cohesion ..
조직이다.. 이건.. 응집력을 높여라.. 같은 조직원이라면 딴 조직 가서 찝쩍 거리지 말고 같은 조직안에서만.. 그것도.. 서로의 행동이나 역할 같은것에 최선을 다 하라는 말이다. 괜히 책임과 권한 혹은.. 가시성혹은.. 복잡도.. 어쨋건... 이런것들이 늘어지게 돼면.. 결국.. Main이 혼자서 모든것을 다 하는 것과 별반 차이가 없는 상황이 발생을 한다. 이것은 피해야 한다. skill이 일부 변해야 하는데.. 엉뚱하게.. NPC의 AI나.. 자료구조가 심각하게 변해야 한다면.. 이건 좀 .. 안좋다는 말이다.. .. 한쪽에서 할수 있는 것은.. 한쪽에서만 하고,, 다른 쪽에서는.. 다른쪽 일만 하면 된다..
나는.. 솔직히 말하면,.. Low coupling과 High Cohesion을 이야기 하면서 항상 이게 서로 정말 다른 이야기 인지 헛갈릴때가 많다..
그 다음은.. Controller여기서.. 의도가 아주 명확해 진다. 외부에서는.. Controller만을 통해서 내부에 접하라는 말이다.. 사실은.. 통해서 접근하는게 아니라.. Controller라는 것으로 장막을 치겠다는 것이다. Controller와만 대화하라.. 대변인이다. (아닌가?? 대변인은 Proxy인가??) 어쨋건.. 모듈 단위 혹은.. DLL단위를 이야기 했을때.. 밖으로 보여지는 부분을 하나로 묶어 거기에 Interface를 모아두겠다는 말이다. 그 이외의 객체에 대해서는.. 아예 알생각도 말아라는 말이다.
좀.. 쉬운듯.. 하게 적었지만.. 대충의 맥락은.. 문제라고 하는 것은.. 잘라서.. 문제가 쉬워질때까지 잘라놓은 후에.. 서로 간에 격벽을 쳐서, 문제 서로 간에 영향을 안받게 하자는 말로 보인다. 모듈화를 하자인데.. 절차적 프로그래밍에 모듈화와는 다르다.. 이것은.. Data와 Module이 같이 있는 형태이다.. (이래서 절차지향에서 객체지향으로 간것 같다) .. 사태의 핵심은 어쨋건.. 누구도 혼자서 모든것을 책임질수 없는 사태에 이르렇고.. 권한과 책임을 분배 해야 하는데 서로간의 코드에 대해서 서로가 골탕먹지 않는 구조로 가는 것이 목적인 것이다. 그래서 서로간의 단절과, 그 내부에서의 단합을 이야기 하고 있다..
아주 기본적이지만 아주 중요한 원칙이다. 분배와 위임의 문제이다.. 하지만.. 너무 기본적인
나머지.. 패턴스러워 보이지는 않는다.. ..하지만 지들이 패턴이라는데 별로 할말은 없다. 정말 중요한 문제는.. 이런것들 모두 고려해서 소프트웨어를 개발한다는 일이 그리 쉽지만은 않다는 말이다.
추신.. 이글을 적은 이유중에 하나는.. GoF의 패턴들을 패턴의 모든것인줄아는 사람들이 있다.
GoF의 디자인 패턴은.. 그야말로.. 시작일 뿐이다.. POSA(Pattern Oriented Software Architecture)를 보면.. 좀더 많은 패턴이 나온다.. 그리고.. 그 후에.. Pattern Language라는 말도 나온다.. .. 너무 머리 아프다.. 하지만.. Pattern은. .. 좋은 약이다.. 잘쓰면.. 수많은 질병을 고칠수 있다.. 하지만.. 너무 맹신하면.. 그 자신을 망친다.
[출처] 패턴이라 하기도 좀 뭣한.... (GRASP)|작성자 유철아빠