객체를 공부하면서... 커플링? 느슨한결합도?

 요즘 공부를 하면서 객체간에 커플링과 느슨한결합도에 대한 다시한번더 생각하게 된다.

내가 주도하는 프로젝트에서야 내가 만든 프레임웍등을 이용할때나 위... 커플링과 느슨한결합도에 신경을 쓸까..?

프리형태의 입장인 지금은 저딴건 개나 줘버렷!!

지금껏 하루 하루 시간 쪼개서 공부해온 것들은 모두.. 내가 주도하거나 내가 주축이 되면.. 가능한것들 뿐이다.

SW공학.. 자체가 비전공자인 내가 공부해봤자라는 의미가 될수 있는듯 하다.

물론 알아두면 좋고 알아야 하는것이기도 하고... 물론 몰라도 돈버는데는 영향이 없어보인다. 


 객체와 객체를 연결지으면서 서로간에 간섭이 얼마나 일어나느냐를 커플링 척도로 보는데 이는 프리로 일하면서

관심밖에 사항이 된다. 결합도 역시.. 그렇다.

느슨하게 해주는 주체가 무엇이 될까?  인터페이스? 추상화된 기반객체?

음... 그렇다면... 내가 주가 되었을때의 이 개념들을 어떻게 써먹을지도 고민해봐야 하는데...

얼마전 완성된 프레임웍은 내부적으론 유지보수에 대한 대비를 많이 했지만.. 실제 사용에 있어서의 결합도는 거의 무시한채 작업이 되었는데... 이건 어떻게 한다?

객체가 객체를 사용하는데 있어서 직접적이 호출이 아닌 중간에 하나를 거쳐서 호출하게끔하여 실제 호출되는 객체의 변화에 조금 덜 반응할수 있도록 맞춰주는것이 결합도를 낮춰주는 방법이라고 난 생각한다.

개발자와 개발자간에 직접적인 업무교류가 아닌 중간에 PL을 거쳐 협업을 하는것 처럼...  이랄까? 비유가 좀 아닌가?

아무튼.. 사용자는 실제 호출되는 객체에 대해 모르는 편이 좋다고 본다. 곧 블랙박스가 된다.
알아야 하는것은 인터페이스.. 정도? 기반클래스에서 제공되는 메서드와 프로퍼티?랄까?

현재의 프로젝트는 인터페이스 기반에 호출이 아닌 해당 객체를 직접 호출하는 형태이다.

또한 객체를 생성하는데 있어서.. 해당 객체를 직접 생성하고 있는데 이를 분리하는것이 곧 생성패턴들을 이용 하는것인데

그런것도 없어보이고... 


느슨함과 커플링에 대한 생각은 좀더 찾아보고 고려해보아야 할 것이다.