모듈화에 대하여 문득

모듈화에 대해서 생각하다가, 의식의 흐름대로 작성하였습니다. 문맥도 두서도 개연성도 없습니다.
대단한 내용은 더더욱 없습니다 !
: )

의식의 흐름 #0.

모듈화를 생각하기에 앞서 나의 코드를 보자.

눈앞에서 흩날리고 있는 코드들 속에서 공통적인/반복적인 부분을 뽑아 내서 중복부터 제거하고. haha. DRY !

의식의 흐름 #1.

개발자는 역할과 책임을 특징 짓고 그것에 따라 적절히 분리할 수 있어야 해. 관찰력이 있어야해.

왜냐하면? 무엇인가를 찾아낼 수 있어야 해.

우리가 찾아야 할 대상은 다음과 같은 일련의 문장들로 표현될 수 있어.

무엇 ?

= 클라이언트에게 알리지 말아야 할 비밀

= 클라이언트가 알 필요가 없는 사항

= 변경될 가능성이 높은 부분

= 복잡하고 어려운 부분

= 세부적인 사항들 및 구현

= 실제 작업해야 할 부분

이런 것들을 찾아내어서 잘 숨기고, 변경될 가능성이 낮은 더 일반적인 개념으로 추상화하여 클라이언트에게 제공되어야 해.

결국 변경에 대비한 적절한 설계를 하라는 것이고 변경이 일어났을때 파급효과를 지역적으로 가두는 것. 그리고 그것이 OCP를 잘 지키는 것 이라고 생각해.

의식의 흐름 #2.

그런데, 여기서 또 중요한 게 있어. 이 추상화를 적절하게 할 줄 알아야 한 다는 것이야. 추상화 레벨을 어디까지 높여야 할 지 판단하는 것은 순전히 개발자의 몫이야.

해당 모듈의 추상화 레벨이 높을 수록 그 모듈의 책임은 많아지고, SRP를 위반하게 될 것 이라 생각해. 반면 너무 낮다면 모듈의 책임은 적어지지만 필요 이상으로 많은 모듈화가 될 수도 있지. 그것은 너무 많은 변경에 대한 대비를 한 것이고 곧 YAGNI 라는 말을 듣게 될테지.

데이타를 제공하는 모듈의 역할을 (= 모듈의 추상화 레벨) 을 어디까지 가져가는 것이 좋을까? 데이타를 준다? 파일로부터 데이타를 준다? 텍스트파일로 부터 데이타를 준다? 그것을 결정하는 것은 개발자야. 이 모듈의 클라이언트와 모듈과의 역할과 책임을 잘 분배하고 아주 아주 잘 생각해보자구.

의식의 흐름 #3.

클라이언트는 해당 모듈의 구체적인 구현(비밀 !!)은 모르고 모듈이 제공한 인터페이스 통해 모듈과 메시지를 주고 받아야해 ! 그 내부를 알 필요도 없고, 알아서도 안돼 !

의식의 흐름 #4.

결국 모두 같은 가치를 바라보는 용어들이라고 생각해.

모듈화.. 추상화… 캡슐화... 역할과 책임의 적절한 분배... 변경에 대비하는 설계...

의식의 흐름 #5.

결국 우리의 지향점은! 일반론만 펼치는 정치인들 같은 뉘앙스로 말하자면.

갑작스런 설계 변경 또는 기능 확장에도 유연하게 대응 가능한 소프트웨어를 만들어야 해