Yagur의 Juggling

작성자: yagur Rev : 2

Around Object Oriented Software - 5

  은닉(Encapsulation, Information Hiding)


  사용자는 공개 노출되는 인터페이스만으로 접근하기 때문에 Engine을 알필요가 없다. Engine 객체는 수면아래로 은닉되는것이라 할수 있다. pimpl 관용구를 통해 구현부안에서도 의존성을 줄이고 있고, 사용자의 응용 영역에 노출되는것은 인터페이스이기때문에 구현을 또한번 은닉하게 된다.
   이 은닉과정을 객체뿐 아니라 이들이 응집된 결과물인 모듈에도 같은 원리로 적용될수 있다. 무엇을 노출하고 무엇을 은닉할지는 결코 쉬운 문제가 아니란것은 아쉬운 부분이다. 하지만 일반화와 추상화를 통해 작은 인터페이스를 만들고, 구현을 은닉함으로서 해당 모듈의 교체를 쉽게 하는것은 모듈의 독립성, 구성력에 큰 도움이 되리라 믿어 의심치 않는다.

 Around Object Oriented Software - 4

  1.모듈성(Modularity)

  객체 지향적인 소프트웨어를 작성하는 커다란 이유 중 하나는 재사용성Reusability과 확장성Extendibility이다. 굳이 객체 지향 개발에 국한시키지 않아도 재사용과 확장은 소프트웨어 개발에 중요한 의미를 지니고 있다. 의도적이던 비의도적이던 어플리케이션 제작을 확장이란 관점에서 보면, 우린 수직적인 추상도를 아래와 같이 그릴수 있다.


  위에서 밑으로 의존성Dependency을 지니고, 아래에서 위로 확장Extending된다 할수 있다. 이들 확장 과정에 생긴 라이브러리들은 일종의 모듈이고, 목적이나 명세에 맞게 그 기능들이 응집되어있다. 그렇다면 이 응집력Cohesiveness의 기준을 무엇에 둘것인지 생각해볼수 있다. 고려해야할 것들은 굉장히 많다. 공통적 특성, 명세, 프로젝트 상황등등 수도 없이 많은 이론과 시공간적인 조건들이 존재한다. 아쉽게도 명쾌하게 이들을 구분하고 구성하는것을 쉬운것과 어려운것으로 분류 해야한다면, 어려운쪽에 속할것이다.
  객체지향을 실현하는 것은 객체란 응집 대상을 디자인하는것이고, 또 이들이 응집되어 파생된 결과물을 모듈화하는것이다. 모듈성을 지니기 위해 여러가지 사항들을 고려해볼수있다.

   1-1 모듈의 독립성(Modular Independability)


  지금 생산중인 어플리케이션은 모듈화 되지 않고, 복잡하게 얽히고 설킨 한그릇의 스파게티인가? 나중에 가서 이들의 응집성을 고려해 모듈화하려하면 어떤 상황이 올지 상상해보자. 이 상상이 즐겁다면 작업물의 생산과정이 타의 모범이 될만한것이고, 이 과정이 괴롭다면 '천재의 손길'과 '엄청난 용기'의 필요성을 느끼기 시작한것이다. Unix의 철학인 KISS(Keep it simple s....)를 항상 염두하고 모듈화한다면, '용기'와 '천재의 손길'의 필요 횟수를 줄일수 있을것이다.
  일부를 수정하기 위해 작업을 할때 변경의 여파를 고려해보자. 이는 모듈화에 필요한 응집성의 기준을 정립하는데 적지 않은 도움이 된다. 이는 모듈의 독립성과 관련이 있는데, 서로 다른 두 모듈은 서로의 변경으로부터 자유로워야 한다는 것이다. 이 글의 수직추상도의 하부에 위치하는 레이어들은 주로 그런 특성을 지니고 있다. 하지만 많은 모듈은 다른 모듈에 연관성을 지니고 있으며, 이는 상위 레이어로 갈수록 더욱 그러하다.
  프로그램 모듈은 언어의 연관성의 세계에서 주로 확장되기 때문에 독립성을 너무 중시하면 생산의 효율이 떨어질수도 있다. 모듈의 위치를 잘분석하고 독립성이란 특징을 잘 해석해 적용해야할것이다.


  위의 그림은 연쇄 반응에 관한 그림이다. 하나에 변경을 주었을때 연쇄적으로 다른것이 영향을 주게 되는것을 그림에서 볼수 있다. 모듈의 연관성이 수직적으로 이루어졌을때, 그 레이어가 높은곳에 있을수록 하위 레벨에 여러 레이어에 의존하고 있을 가능성이 크다. 이 경우 하위 레이어(혹은 모듈)의 변경이 있을경우 상위 레벨 레이어(혹은 모듈)들은 연쇄적으로 오동작하는 반응을 보인다.


  이때 수평적인 관계에 있는 모듈(레이어 깊이 레벨이 같은경우)들이 연관되어 있다면 상하개념이 아닌 수평적인 위치에 있는 모듈들까지 이 연쇄 반응에 휘말리게 된다. 나비효과Butterfly Effect를 벗어나려면 수평적 위치(같은 레벨의 레이어)에 속한 모듈들은 서로간의 의존성을 끊고 서로간에 독립성을 보장해주는것이 좋다. 그렇다면 이들은 서로 변경의 영향력에서 벗어나, 변경의 연쇄 반응에서 벗어날수 있다.


  최악의 연쇄반응을 잃으키는 방법들중 몇가지를 소개하자면 소프트웨어 동작 플랫폼 교체, 언어의 컴파일러 버젼을 옛날것으로 바꾸기 등이 있다. 개발자에겐 핵폭팔과 같은 연쇄반응을 잃으키지 않을까? 이 독립성 보장은 모듈의 분해력, 구성력과 관련이 있다.



  1-2 모듈의 분해력(Modular Decomposability)

  거대한 모듈 혹은 여러 기능이 응집된 모듈은 공통의 문제 영역을 위해 응집되어있다. 이들은 더 작은 하위 문제 영역(subproblem domain)으로 분해될수 있다.

  너무 많은 분해는 의존성 복잡도를 증가시켜 관리하는데 어려움을 주지만, 적절한 분해는 재사용성을 증대시키고 변경 영향력의 확산을 줄여줄수 있다. 이때 고려해야할 사항은 모듈의 레이어상의 위치, 그리고 이들의 의존성 관계이다. 의존성은 최대한 줄여 독립성을 최대한 보장하고, 그 연결고리를 명확히 해야한다. 그래야 책임과 분배가 더욱 쉬워진다.
  명확한 의존성 정의에 관한 예를 하나 들어 보자. "이 수학 라이브러리를 업데이트 하려면 인텔 컴파일러가 필요하다. 하지만 컴파일된 결과물은 비주얼 C++에서도 링크해 사용할수 있다." 라는 의존성 정의는 사용자나 개발자가 절대 알아야할 의존 정보이다. 의존성이 명확하기 때문에 사용자는 인텔컴파일러를 써서 컴파일하고, 응용프로그램 제작시엔 비주얼 스튜디오에서 링크해 개발을 진행할수있다. 이런 사소한 컴파일 지침도 의존성이 존재한다. 복잡하고 엔트리가 많은 소프트웨어 모듈은 더욱 명확한 의존성 정의가 필요할것이며, 간결하고 그 수가 적을수록 구성Compose에 효율성을 띌것이다.
  분해력을 지니되, 역으로 분해된것이 어떻게 구성되어질지를 염두한다면 좋은 모듈의 구조를 이루는 첫발이 될것이다.


  1-3 모듈의 구성력(Modular Composability)

  모듈은 문제 영역에 따라 구분된 재사용 가능한 집합체이다. 이 모듈을 재사용해 하나의 시스템을 구성하지 못한다면 재사용성이 매우 떨어진다고 볼수있다. 그리고 이는 모듈이라 부르기에 부끄럽다.

작성자: yagur Rev : 1

 Around Object Oriented Software - 3

 다형성(Polymorphism)

  Poly는 '많은(多)'이란 뜻을 가지고 있고 morph는 '형(形)'이란 뜻을 가지고 있다. polymorph는 다형으로 번역되고 있으며 polymorphism은 다형성을 뜻하고 있다. 다형성이란 무엇일까? 다수의 형을 가진 성질이라고 해석하면 되지만 다수의 형을 갖는것이 어떤 것인지는 예를 보기전엔 알기 어려운 단어이다.


  미녀와 야수에서 야수는 저주에 걸린 왕자이다. '그'는 저주를 받은 인간으로 야수의 모습을 하게 되었다. 우리가 소설속 남자 주인공을 지칭하는 '왕자'란 추상적 객체는 시간에 따라 여러 가지 형을 지니게 된다. 저주 받기 전인 과거에는 인간으로서 '왕자'였고, 저주 받은 상태의 현재엔 야수의 형태를 지닌 '왕자'이다. 또 공주를 만나 시간이 흐른 미래에는, 저주가 풀리면서 다시 인간의 형태를 지닌 '왕자'가 된다.
  컴퓨터 언어의 코드 플로우에도 과거와 현재, 그리고 미래를 지니고 있다. 그리고 '그'(왕자)를 코드로 재미 삼아 표현해 본다.

미녀와 야수 코드 샘플

 #1에서 그(' pHe ')는 인간이다.
 #2에서 그는 야수이다.

  pHe 개체의 객체인 Actor는 프로그램의 흐름에 따라 다형성을 지니는 것을 알수 있다. 역활의 추상화Abstraction으로 만들어진 Actor 객체는 대부분의 역활을 지칭하는데 쓰일수 있으며, 다형성을 지니고 있다. 이것이 주는 이점중 하나는 은닉Encapsulation이다. 사용자는 실체가 무엇인지 몰라도 추상 객체를 통해 흐름을 진행시킬수 있다. 위와 같이 추상화를 통해 실현된 다형성은 상속을 기반으로 한것이다.


 행위 기반 다형성(Behavior based polymorphism)

  정적 타입 언어는 상속 관계를 통한 다형성을 구현하지만 다른 방식의 다형성도 존재한다. 행위만 동일하다면 관계에 상관없이 다형성을 지니게 되는 경우이다. 이 행위 기반 다형성은 동적 타입 언어와 정적 타입 언어에서 모두 나타나지만 차이점이 존재한다. 그 차이점은 언제 다형성을 지니는것인가 이다.
  정적 타입 언어의 특징상 행위 기반 다형성을 컴파일 타임에 템플릿을 통해 지원한다. 동적 타입 언어는 형 변경의 제약이 없기 때문에 실행시간에 해당 다형성을 지원하고 있다. 동적 타입 언어에서 실현되는 행위 기반 다형성을 Duck-typing이라고 한다.
  하지만 Duck-Typing 역시 약속된 행위를 객체가 지니고 있어야 다형성을 지닐수 있다. 상속을 배제하고 행위를 런타임중에 확인할수 있는 언어의 특징상 생긴 기능이라 볼수 있다. 이는 정적 언어와의 성능차이로 이어진다. 양쪽 타이핑 모두 일장일단을 지니고 있다.

작성자: yagur Rev : 2

 Around Object Oriented Software - 2

 2. 추상



 추상화(Abstraction)

  프로그래밍을 접해본사람은 '추상'이란 단어를 아마 수백 수천번은 보고, 듣고 했을것이다. 이 추상화Abstraction란 기술은 객체 지향 프로그래밍에서 중요한 여러 기반 기술 중 하나이다.
  우리가 자주 하는 추상화는 말속에 들어있다. "이것" "저것"과 같이 대상을 지칭을 하거나, "과일" "동물"과 같이 공통점에 의해 개체Instance들을 객체Class로 분류 하거나, 숫자나 기호와 같이 약속된 의미를 두기도 한다. 이들은 모두 구체화되지 않고 그 자체만으로는 '개체화Instantiation가 불가' 하다는 공통점을 가지고 있다. 예를들어 "과일"이란 객체만으로 개체를 만들기엔 구체성이 부족하다. '내가 먹을 책상위의 바나나'란 개체로 과일을 개체화하려면 '노란 껍질에 모양이 휘고, 단맛을 지닌' 바나나라는 구체적인 객체가 필요하다.
  대상을 지칭하는 추상의 개념은 컴퓨터 언어속에도 존재하고 있다. C++과 Java에선 this 그리고 Python에서는 self라는 키워드로 객체 자신을 지칭할때 사용한다. 혹은 '이미 개체화된 객체'를 사용자가 레퍼런싱 함으로서 대상을 지칭하는 용도로 쓰인다.
 예를 들자면 아래와 같다.

ex> 자신 지칭


ex> 상위 분류로 지칭

 피카소의 추상화抽象畵를 보면 개체가 가지는 특징(윤곽)을 나타내 추상화Abstraction한다.
  원본 그림을 몰랐다면 연상이 안될수도 있다. 하지만 구체적인 것(추상화 대상)을 안다면 추상화된 결과물을 보고 무릎을 탁칠수도 있는일이다. 피카소의 그림은 공통 윤곽을 잡아 기하학적 추상화를 하고있는것으로 보인다. 컴퓨터 언어의 객체 추상화도 다를것이 없다. 서브 클래스들의 공통 분모를 찾아 슈퍼 클래스로 일반화 하기도 하며, 추상 객체인 슈퍼 클래스를 미리 정의 해놓고 하위 클래스로 서브클래싱하기도 한다. 이들을 상속 관계Inheritance에 있다고 한다. 그리고 상속은 객체 지향 프로그래밍의 기반 기술중 하나이다.
  추상화는 단계적으로 이루어질수도 있다. 피카소가 소를 단계적으로 추상화하는것이 인상적이다.

작성자: yagur Rev : 2

 Around Object Oriented Software - 1

 1. 객체


  근 십수년간 Object Oriented Programming의 패러다임은 바이러스와 같이 퍼져나갔다. 그리스 철학자 플라톤의 이데아론의 영향을 받은 패러다임은 사람들의 입담과 종이위의 글, 또는 소프트웨어의 코드란 실체 통해 그 철학을 전염시켜 나갔다. 그리고 지금 그것의 위치는 가장 널리 보급된 패러다임이 되었다.


  재미있는 글귀이다. 객체 지향 프로그래밍을 하던 사람에게 매우 친숙한 단어들이 보인다. 객체Class 그리고 인스턴스Instance가 바로 그것들이다. 칼릴의 격언처럼 우린 생각 영역에 있는 추상의 것들을 프로그래밍의 객체Class로 정의해 코드란 것으로 개체화Instantiation시킨다. 그리고 우리는 코드로 개체화된 컴퓨터 언어 영역의 객체를 메모리의 세계에 개체화 한다.
  카릴의 격언중 '말'이란 부분을 컴퓨터 언어(C++, Java등)로 해석하면 꾀 그럴사 하다. 우리가 객체 지향 프로그래밍을 하며 가장 많이 하는 것이 무엇이 있을까? 바로 연관 관계를 디자인하거나, 그것들을 프로그램으로 실체화 하는 것이다. 이 연관 관계를 구체화한것들은 OOP에 매우 친숙한 객체 관계Class Relationship들이다.

  연관 관계를 위와 같은 모델링 언어로 표현하기도 한다. 상속Inheritance, 합성Composition, 집합Aggregation, 연관Assocation, 위임Delegation등의 관계는 경험자에게 친숙한 관계들일것이다. '직선과 화살표 그리고 << >>의 스테레오 타입'으로 표기한것은 '결합관계를 스테레오 타입'으로 나타내는 방언으로 봐도 무방하다.
  우리가 실체화한 객체는 추상의 세계로부터 나왔다. 그리고 추상적 개념을 띄고 소프트웨어의 내부 구성원인 객체로서 우리의 창조물이 된다. 우리가 말(Computer Language)을 할때 추상적인 것들 사이의 연관 관계를 정의함으로서 우린 오류를 범할수 밖에 없다. 하지만 연관성의 오류가 소프트웨어의 동작을 멈추게 하는것은 아니며, 소프트웨어에 나쁜 냄새(Refactoring의 냄새 혹은 OOD의 나쁜 설계)를 풍기게 할뿐이다.

  우린가 무엇으로 객체를 식별하는지, 그 기준을 생각해 보는것도 나쁘지 않다.