Taegony's blog

날짜 : 2009-06-24
코스 : 동호대교~한남대교~반포대교~동작대교 왕복
거리 : 10 km
시간 : 01:04:04

요즈음 근력운동을 계속 하고 있다.
그래서인지 뛸 때 몸에 힘이 좀 붙었단 느낌이 들었다.
지구력도 한달 전 보다 좀 좋아진듯 하다.
확실히 난 근력이 모자란게 문제였던 것 같다.
계속해서 근력운동을 해주면 앞으로 달릴 때 많은 도움이 될 것 같다.
날씨가 좀 더운 편이라 밤에 뛰었는데도 땀을 한 바가지 흘렸다.
결국 오늘도 라면에 밥말아먹고 자야할 것 같다. ㅋ

문제
어떻게 하면 같은 제품군에 속한 제품들의 객체만을 생성해서 사용하도록 명확히 보장받을 수 있는가?
예를들어 타입A 제품의 종류는 A1, A2가 있으며 타입B 제품의 종류는 B1, B2 가 있다.
제품 생산시 1번 제품군은 A1, B1이며 2번 제품군은 A2, B2이다.
조건에 따라 제품군으로 분류된 제품만을 생성해야 한다.

방법1
- 제품군을 생성할 때마다 조건 비교를 한다.
- 이 방법은 조건문이 곳곳에 들어가게 된다.
  추후 제품이 추가되는 경우 조건문이 들어간 부분을 모두 찾아서 수정해야한다.
  아래 코드와 같이 생성함수에서 추가된 제품의 종류를 비교해야 한다.
- 샘플
[code cpp]
class productA {};
class productB {};
class productA1 : public productA {};
class productA2 : public productA {};
class productB1 : public productB {};
class productB2 : public productB {};

void CreateProductA ()
{
  ...
  if (iType == 1) {
    productA1 pa1;
  }
  else {
    productA2 pa2;
  }
  ...
}

void CreateProductB ()
{
  ...
  if (iType == 1) {
    productB1 pb1;
  }
  else {
    productB2 pb2;
  }
  ...
}

int main ()
{
  ...
  CreateProductA ();
  CreateProductB ();
  ...
}
[/code]

방법2
- Factory Method 패턴에서 사용했던 팩토리 메소드를 가진 클래스를 제품군별로 생성한다.
- 이점
  1. 개별 제품 클래스의 객체를 생성할 때마다 일일이 조건을 검색할 필요가 없어진다.
  2. 새로운 제품군의 생성시 기존 소스코드는 건드릴 필요가 없다.
  3. 팩토리 클래스가 별도로 존재하기 때문에 클라이언트는 추상클래스의 인터페이스만 바라보면 된다.
  4. 반드시 선택된 제품군에 포함된 제품들만 생성해야하는 경우 유용하다.
- 단점
  1. 제품군이 늘어나면 어쩔 수 없이 팩토리 클래스의 수도 늘어나게 된다.
  2. 기존 제품군에 새로운 제품이 추가되면 모든 팩토리 클래스에 새로운 제품을 추가해야한다.
- 샘플
[code cpp]
class AbstractProductA {};
class AbstractProductB {};
class ProductA1 : public AbstractProductA {};
class ProductA2 : public AbstractProductA {};
class ProductB1 : public AbstractProductB {};
class ProductB2 : public AbstractProductB {};

class AbstractFactory
{
  public:
    virtual productA* CreateProductA () = 0;
    virtual productB* CreateProductB () = 0;
};

class Type1_Factory : public AbstractFactory
{
  public:
    AbstractProductA * CreateProductA () {return new ProductA1;}
    AbstractProductB * CreateProductB () {return new ProductB1;}
};

class Type2_Factory : public AbstractFactory
{
  public:
    AbstractProductA * CreateProductA () {return new ProductA2;}
    AbstractProductB * CreateProductB () {return new ProductB2;}
};

int main ()
{
  ...
  AbstractFactory *pFactory = null;

  if (iType == 1) {
    pFactory = new Type1_Factory ();
  }
  else {
    pFactory = new Type2_Factory ();
  }
 
  AbstractProductA *pProductA = pFactory->CreateProductA ();
  AbstractProductB *pProductB = pFactory->CreateProductB ();
  ...
}
[/code]

특이한 소재를 좋아하기에 평범하지 않은 제목으로 보이는 이 책을 살 수 밖에 없었다.
도데체 무슨 내용일지 무척이나 궁금하게 만드는 제목이었다. ^^;
하지만 제목 때문에 기대했던 내용과는 다르게 한 자폐증 소년의 세상과의 소통이야기이다. 한밤중에 개에게 일어난 의문의 사건은 이야기의 시작일 뿐이다.

주인공 소년은 수학과 물리에 천부적인 재능을 타고 났으며 숫자와 같은 것에 대한 기억력이 상당히 비상하다. 하지만 세상 사람들의 감정을 이해하지 못한다. 또 누군가 자신과 스킨쉽을 하는 것조차 거부한다. 이 소년에게 한 가지 의문이 생겼다. 도데체 누가 옆집개를 죽인 걸까? 소년은 이 사건을 해결하고 싶어한다. 그리고 실행에 옮기기위해 세상과 접속하게 된다. 굉장한 추리력으로 사건을 해결하고 책이 끝날 것이라는 내 추측과는 달리 범인은 싱검게도 중간에 밝혀진다. 하지만 그로인해 소년은 또다른 모험을 하게된다.

읽다보니 작가의 소년에 대한 내적 묘사가 뛰어난 것인지 나도 자폐증이 있는 것인지 소년의 모든 행동에 이상한 점을 발견할 수 없었다. 아마도 작가가 소년의 생각을 잘 묘사했기 때문일 것이다. 이 부분 때문에 상충된 두 가지의 생각을 하게 됐다.
첫째는 서로 같은 세상에 살면서 단지 생각의 기준이 다르기 때문에 (좀 많이) 자폐증이라는 병명을 붙여주고 그들의 생각하는 방식을 치료한다는 명목으로 강제하려고 하는게 과연 옳은 것인가라는 생각과
둘째는 사람이라는게 속성상 함께 살아야하는데 너무나도 다른 기준으로 사는 사람이라면 함께 하기 힘들지 않을까? 그 사람이 혼자 살 능력이 된다면 내버려두겠지만 그렇지 않다면 보호를 해줘야하고 그럼 함께 살아야한다는 말인데 결국 그 사람의 생각을 바꾸도록 하기위해 노력해야하는 것이 맞는 것 아닌가!
난 두 번째가 맞는 것 같다. 하지만 내 선택에 대해 약간 뭔가 석연치 않은 여운이 남는다.

무의식적으로 당연하다고 생각되는 보편적인 내용들을 소년은 왜 그런건지 이해를 하지 못하며 또한 간단명료한 논리로 그걸 무시해버리고 자기생각대로 행동한다.
하지만 이런 내용들이 나로 하여금 보편적인 내용이 잘못된 듯한 느낌을 받게했다.
내 스스로 보편적인 것에 대해 길들여진게 아닌가 하는 생각을 하게 했다.

마지막에 소년은 레벨A의 수학 시험을 A학점으로 패스하게 되면서 자기 인생에 대한 계획을 말한다. "레벨A 물리 시험도 또한 A학점으로 패스할 것이고 대학에갈 것이고 ..." 그리고 아버지로부터 새로운 강아지를 선물받는다. 새로운 시작이 느껴지는 부분이다. 점점더 세상과의 소통을 넓혀가는 모습에서 희망의 메시지를 본 것 같아 기분 좋게 책을 마무리 할 수 있었다.

[인상 깊었던 말]

- 나는 소수가 인생과 같다고 생각한다. 소수는 매우 논리적이지만, 당신이 한평생 생각하더라도 소수가 만들어지는 규칙은 결코 알아낼 수 없다.

- 오컴의 면도날 이론
절대적으로 필요한 것보다 더 우선되는 가치는 없다.

객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스에서 책임지도록 한다.

유용한 경우
- 구체적으로 어떤 클래스의 객체를 생성해야 할지 미리 알지못하는 경우
- 객체의 종류별로 객체 생성과 관련된 부분을 국지화 시키는 경우

장점
- 어떤 객체를 생성할 것인지와는 무관하게 동일한 형태로 프로그래밍이 가능하다.
  ; 당연하다. 클래스 상속을 통한 다형성을 구현하므로 ...
- 클라이언트가 직접 객체를 생성하는 것보다 유연한 확장성 구조를 가지게 된다.
  ; 새로운 객체를 생성하거나 이전 객체를 확장해서 생성하고자 할 때
    새로운 하위 클래스를 정의하고 Factory Method에 해당하는 멤버 함수만
    Override 시키면 된다.
  ; 다시 말하자면 객체 생성과 관련된 변경을 국지화 시킬 수 있다.
- 서로 연관된 클래스들의 상속관계가 병렬로 존재하는 경우 한 쪽 상속 관계의
  클래스들이 다른 쪽 상속 관계의 클래스 객체를 생성할 때 유용하다.
- 상속관계에 있는 클래스들의 멤버 함수가 동일한 프로그램 로직을 가지고 있으면서
  내부적으로 생성할 객체만 서로 다를 때 편리하다.
  ; 로직은 상위클래스에서 구현하고 생성과 관련된 부분만 하위 클래스에서 구현한다.

단점
- 객체의 종류가 달라질 때마다 새로운 하위 클래스를 정의해야한다.
  ; 따라서 불필요하게 많은 클래스들을 내포할 가능성이 있다.

[뱀발바닥]
패턴의 유용성을 알리기 위해 좀 어거지라고 생각되는 예를 (지극히 내생각이다.) 들었다는 느낌이 많이 들었다. GoF 패턴에 대한 해설서이므로 저자가 의도적으로 설명하기 위해서 그렇게 한 것 같긴 하지만 나에겐 좀 아쉬운 부분이다. 하지만 아직 이쪽부분에 대해 용어나 표현에 대해 미숙하기 때문에 그렇게 생각하는지도 모르겠다. 어쨌든 패턴이라고 하는 영역이 소프트웨어를 설계할 때 많은 도움이 되리라고 확신하지만 너무 이쪽 이론에 빠지게 되면 자칫 말장난에 빠질 수도 있겠다는 생각이 든다. 패턴은 객체지향언어를 제대로 쓰기 위해 필요한 기본적인 테크닉일 뿐이라고 생각한다. 나머지는 자신의 영역에 맞게 적용하는게 문제라고 본다. 뭐 그게 어렵겠지만 ㅋㅋㅋ

병원에서 벌어진 일들을 에피소드 형식으로 묶어서 하나씩 소개했다.
의사, 환자 그리고 그 가족들에 대한 이야기를 잔잔한 문체로 진행했으며 읽어갈수록 점점 빠져들게하는 묘한 매력을 지닌 책인 것 같다.

난 본래 의사들을 별로 좋아하지 않는 편이다.
적어도 나에게 의사들이란 인간성도 별로 좋지 않고 머리만 좋은 냉혈한들로만 보였기 때문이다.
사실 감기 같은거 아니면 병원에 갈 일이 별로 없는 편이라 그런지도 모르겠다.
그리고 가끔 부모님 모시고 병원갔을 때의 안좋은 기억들 뿐인지라...
책을 보면서 이런 점들이 좀 깨진 것 같다.
이런 의사들도 있구나 하는 생각과 함께 지금까지 '의사=냉혈한' 이라고 하는 이미지에 변화가 왔다.
하기사 사람을 하나의 이미지로 묶어버린다는게 얼마나 위험한 일인가 나는 그런 식으로 말하는 사람들을 비난 하면서도 나조차도 그런 생각을 하고 있었다.

병원 동료, 환자들의 이야기를 통해 인생이라는게 뭘까하는 물음과 함께 그래 그런게 인생인 것 같다는 내 나름의 막연한 답을 동시에 느끼게 해주는 책이었다.
아울러 종합병원 생활을 청산하고 친구들과의 약속을 위해 하동으로 내려가 함께 병원을 운영하는 모습이 많이 부러웠다.

처음엔 시골의사라고 하는 별명이 경제와 관련한 해박한 지식때문에 붙여진줄 알았다.
그런데 알고보니 진짜 외과 의사였다.
전문 분야를 이렇게 두 가지씩이나 잘 한다는게 부럽기도하고 난 뭔가 하는 자괴감 같은게 들기도한다. ㅋㅋ

날짜 : 2009-06-07
코스 : 동호대교~한남대교~반포대교~동작대교 왕복
거리 : 10 km
시간 : 01:05:34

오늘부터는 오전에 뛰기로 결심을 했는데 어제 새벽 늦게서야 겨우 잠이 드는 바람에
결국 또 늦잠을 자고 말았다.
하루 종일 퍼질러 있다가 오후 4시가 되어서야 겨우 한강으로 기어나갔다.
생각보다 날씨가 그렇게 덥지 않다고 생각했는데 의외로 땀이 많이 났다.
그리고 왠일인지 다리에 무리가 좀 가는 듯한 느낌이 들었다.
겨우 10 km 뛰는데 이러면 곤란한데 ... ㅋㅋ
얼마전부터 컨디션 회복을 위해 근력운동을 해주고 있다.
이틀에 한 번 꼴로 상체만 해주고 있는데 하체쪽도 가볍게 해줘야할 것 같다.
집에서 하는거라 뭘 해야할지 모르겠지만 할 수 있는게 있는지 한 번 찾아봐야겠다.
그리고 7월 쯤에는 런닝화도 한 켤레 구입해야겠다.
밑창이 더 두꺼운 놈으로 사려고 한다.
내건 아무래도 좀 얇지 싶다.

- 회사에서 웹쪽관련 업무에 대해서 맡으라는 말을 했다.
  주로 ASP.NET 베이스의 UI 관련 업무이다.
  답변은 싫다였고 실랑이가 오가다가 사표얘기까지 나왔다.
  다른 업무는 다 받겠지만 UI 관련 업무는 못하겠다고 했다.
  잘 한 일인지 잘 모르겠다.
  월요일에 본사로 복귀하면 다시 얘기가 오갈텐데 골치가 좀 아플 듯 싶다.

- 회사가 어려워 지면서 1가지 제품에 대해서 주력하는 것으로 정책이 정해졌다.
  그런데 현실은 도저히 그렇게 할 수가 없는 상황이다.
  기존의 유지보수 업무와 관련해서도 아직 많은 업무들이 들어오고 있기 때문이다.
  방법은 두 가지 정도로 생각된다.
  첫째는 완전히 타제품에 대한 라인을 없애버리는 것.
  둘째는 타제품의 라인을 가져는 가는대신 팀장 권한으로 스케쥴을 늦추는 방법.
         타제품에 대한 주당 작업량을 5일에서 1일로 줄이는 방법.
         나머지 시간은 집중하기로한 1가지 제품에 투입한다.
  둘 다 어렵다.
  첫번째 방법은 고객사에 타사제품이 들어오기 시작하면 우리 회사의 주력제품도 위험해진다.
  두번째 방법은 당장 시급한 문제가 발생한 상황에서 이런 식으로 할 순 없다.
  그렇다면 하나 더 생각할 수 있다.
  평소에는 두번째 방법을 진행하되 급한 경우 유지보수 업무에 주력하다가
  클리어되면 다시 주력제품에 투입한다.
  아마도 이런 식으로 진행될 듯 싶은데 현실적으로 이게 가능할지는 나도 잘 모르겠다.
  왜냐하면 주력한다는 제품에 대해서 아는 사람이 별로 없기 때문이다.

- 요즈음 나름대로 근력운동을 하기 시작했다.
  대단한 건 아니고 주당 3회정도 팔굽혀펴기 (와이드), 이두근, 어깨, 윗몸일으키기,
  악력기 (양손 100회) 씩 하고 있다. 아직 시작단계지만 나름 재미가 있어서 즐기면서
  해보려고 하고 있다. 근력 운동을 하는 대신 조깅은 주 1회만 한다.

- 쓰고 있는 플랭클린 다이어리를 가능하면 많이 활용하려고 한다.
  그 동안 쓰다말다를 반복했지만 지난 달엔 많은 목표를 세우고 체크해나갔다.
  목표를 세우고 그 날일을 체크해보고 하는 부분이 시간이 많이 걸리지는 않지만
  흐트러질 수도 있는 내 마음가짐을 다시 잡아주는 역할을 해주는 것 같다.
  아직 미흡하지만 최대한 활용하도록 노력해보고 싶다.

- 요즈음 디자인 패턴을 보고 있다.
  예전부터 사둔 책인데 이제서야 보고 있다. 보지도 않은 책이 참 지저분하다.
  오래되긴 했나부다.
  책을 보고 패턴을 그려보고 다시 샘플코드를 자동생성해보는 식으로 진행하고 있다.
  사용하고 있는 툴에 대한 지식이 별로 없어서 아직까진 좀 힘들다.
  내가 진행하는 프로젝트에 응용할 수 있기를 기대해 본다.
  내 생각에 책에 나온 그대로는 무리이지 싶고 개념에 대한 응용이 중요하다고 본다.

- 다행히 독서를 조금씩이지만 꾸준히 하고 있다.
  아직 책을 읽는 방법이 문제가 있어보이지만 계속 읽다보면 좋아질거라는 생각이든다.
  요즈음 책을 보는게 재미있다.

- 오밤중에 TV를 보는걸 좀 줄이고 싶다. 그런데 쉽지가 않다.
  늦은 시간이라 볼 것도 없으면서 계속 틀어댄다.
  예전 나의 불면증에 한몫 한 부분이다.
  의식적으로 줄여봐야겠다. 요즈음엔 시간이 아깝다는 생각이든다.