Yagur의 Juggling

 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)

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