Application Design

2. 어떠한 객체도 혼자서 모든 일을 할 수 없다.(재사용성)

멋진그이름 2017. 3. 24. 10:41

<개요>

객체지향 디자인은 일반적으로 서양에서 일반적으로 다루는 철학적 사상을 배경으로 하고 있기 때문에 동양 사고에 익숙한 사람들은 잘 와닿지가 않는 듯 하다.

 

 현장에서 경험하고 여러가지를 공부하여 이해한바를 바탕으로 큰 특징을 잡아서 설계관점에서 접근해보면 좋을 것 같다는 생각에 정리를 해본다.

 

 

<내용>

1. 상호의존

 

- 객체지향 디자인에서 나오는 산출물을 크게 정적, 동적으로 나누어 본다면 정적에서는 Class Diagram, 동적에서는 Seq Diagram으로 볼 수 있는데 이는 결국 각 객체의 의존관계를 표현하기 위함이다.

<그림-1 다이어그램의 분류>

 

 

 

<그림-2 Class Diagram>

 

<그림-3 Seq Diagram>


 

 우리나라 사람들이 이러한 Diagram을 그리기 어려워 하는 것도 결국 사고의 방식이 서양과 다르기 때문이 아닌가 생각해본다. 서양인들은 카테고라이징에 강하고 동양인들은 릴레이션에 강하다고 한다.

(호랑이, 원숭이, 바나나 중에서 관계가 있는 것끼리 묶으라고 하면 서양인들은 같은 동물인 호랑이, 원숭이를 선택하고 동양인들은 원숭이, 바나나를 선택한다고 한다...)

 

 - Class Diagram은 결국 우리가 개발할 때 필요한 객체들을 카테고라이징 한 결과물이고

 - Seq Diagram은 그 객체들이 주고 받는 메시지를 정의한 것이다.

 

 - 특히 Seq Diagram상의 메시지는 기능 (method, function, API등) 의 argument, return 타입을 정의하기 때문에 매우 중요하며 각 객체가 주고받는 내용을 포함하기 때문에 결국 각 객체의 책임을 명확하게 정리하는데 많은 도움이 된다.

 

 <Tip>

 Class Diagram은 분류에 집중하고, Seq Diagram은 메시지와 Life Cycle에 집중하면 좋은 결과물이 나온다.

 

 핵심 : 내가 처리할 수 있는 것은 필요한 정보를 받아서 처리 후 결과를 다른 객체에 알려준다. 내가 모든 것을 처리하지 않는다.

 

 

 

2. Coupling & Cohesion

 

 - 이렇게 각 객체를 도출하여 개발을 할 때 어떤 객체가 특정 객체에서만 참조 된다면?

   이런 경우 우리는 Coupling이 강하다고 한다.

 - 이렇게 만들어진 객체는 다른 객체와 협력하기 어렵다. 즉, 재사용성이 낮다.

 - 여러 곳에서 두루 사용될 수 있도록 객체를 설계해야 하며 이를 Cohesion이 높다고 한다.

 - 수년간 프로그램 개발을 하면서 얻었던 몇가지 Tip을 공유하자면 !

 

  <Tip> - 추후 자세히 설명!

  a. Seq Diagram에서 표현되는 메시지, 즉 메소드의 인자값을 유연하게 가져가야한다.

 

  b. ~ is a~ 의 관계보다 ~ has a ~ 의 관계를 가져가도록 노력해야 한다.

 

  c. Class를 설계할 때에도 ConcreateClass보다 Interface와 Abstract를 적극 활용한다.


 

 

3. God Object 를 피하라

 - 1,2번과 연관이 있는 내용이다.

 - 즉 혼자서 모든 것을 처리하는 객체를 만드는 것을 피해야한다.

 - 특히 개발기간이 짧고 소수의 개발자가 투입될 때 많이 나타나는 모양인데 프로젝트 종료 후 반드시 리팩토링을 거쳐야만 한다!!

 - Design Pattern에서 언급되는 대표적인 Anti-Pattern으로 유지보수성이 매우 낮고

  (만든 사람만 고칠 수 있다;; 그래서 개발자로 오래 살아남는법 이라는 책에서는 이렇게 만들라고 권장한다!)

 - 모든 일을 혼자서 다 처리한다는 이야기는 결국 모든 요구사항과 연결되어 있다는 내용이고 매번 고쳐야하는 객체라는 이야기이다. 즉, 재사용성이 낮다.

 

 

<결론>

 - System이라는 말이 한자로 바꾸 가 된다.

 - 우리가 살고 있는 생태계도 여러종류의 생물, 무생물이 각각의 역할을 수행하고 다른 객체와 소통하여 유지가 되고 있는 것처럼

 - IT System도 여러가지 역할이 적절히 분배된 객체들이 잘 어울려야 안정적인 System을 구현할 수 있다.

 - 다양한 다른 객체와 원활하게 소통할 수 있도록 만들어진 객체는 오래 살아남을 수 있지만, 그렇지 않게 설계된 객체는 System상에서 오래 살아남기가 어렵다 (재사용성 측면)

 - 객체지향에 익숙하지 않거나 싫어하는 개발자는 Operation(method, function) 의 Argument나 Return Type을 신경쓰지 않는 경향이 있다. 협업을 위해서 조금만 더 신경써주세요!

 - 전역변수를 주로 사용하고 argument는 비어있고, return 은 void 가 일반적이다;;

   객체지향에서 항상 나오는 캡슐화 와도 연관이 있는데 정말 안 좋은 습관입니다.

 

 

<참조사이트>

https://en.wikipedia.org/wiki/Class_diagram