응집도와 결합도
좋은 설계를 하기 위해 고민할때, 일반적으로 유지보수를 용이하게 해주는 설계일 것이라 생각됩니다.
그런 면에서 좋은 설계는 높은 응집도와 낮은 결합도를 가지도록 구성해야 합니다.
응집도
응집도는 모듈에 포함된 내부 요소들이 하나의 책임/목적을 위해 연결되어있는 연관된 정도
- 모듈이 하나의 목적을 수행하는 요소들간의 연관성과 척도
- 모듈 내부의 기능적인 응집 정도를 나타냄
- 유지보수를 한다고 생각 했을때, a 라는 기능을 수정하기 위해 A 모듈만 찾아서 수정하면 편할거 같아
- 응집도가 높으면, 변경 대상과 범위가 명확해지는 장점이 있어 수정하기 쉬워짐
🤔 J_nny 그럼 새로운 메소드를 만들때에도, 모듈과 기능의 관계를 생각해보아야겠다.
결합도
결합도는 다른 모듈과의 의존성 정도. 모듈 수정을 위해 다른 모듈의 변경을 요구하는 정도
- 모듈이 다른 모듈에 의존하는 정도의 척도
- 모듈과 모듈간의 상호 결합 정도
- b라는 기능을 수정하기위해, b 기능이 모여있는 B모듈을 수정하는데, 다른 모듈들의 소스도 봐야하고, 필요시 수정까지 해야한다면 유지보수가 더욱 힘들 것
🤔J_nny 모듈과 모듈 사이에는 서로 영향이 없을 수록 좋은것이네. 결합도가 높아지면 수정해야할 것들이 늘어나니깐.
응집도를 높이는 순서로 정리해서 코드가 명확해지면, 결합도 역시 좋아질 수 있음
인터페이스에 의존하는 코드 작성은 낮은 결합도를 얻을 수 있음
이를 위해 나온 법칙들이 의존성 주입, SOLID.. 등등 이런것들은 다음 포스트에서 정리 해봐도 좋을 것같다. 가장 인상깊었던 내용을 하나 정리해보자면,
SOLID
1. SRP 단일 책임 원칙 : 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
2. OCP 개방 폐쇄 원칙 : 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.
3. LSP 리스코프 치환 원칙 : 서브 타입은 언제나 자신의 기반 타입을 교체할 수 있어야 한다.
4. ISP 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다.
5. DIP 의존 역전 원칙 : 자신보다 변하기 쉬운 것에 의존하지 마라.
이런 객체지향 프로그램을 편리하게 해주는 것이 Spring Framework 이다.
회고
개발을 할때마다, 원하는 화면대로 구현하는데는 얼마걸리지 않는데 최근 들어서는 어떻게 하면 유지보수할 때 편할까라는 고민을 하다보면 시간이 훌쩍 지나있다. 그 시간을 줄이기 위해서 처음부터 가독성이 좋은 코드를 작성해야하는데 아직 많이 부족함을 느낀다.
이러한 개념들이나 팁들을 정리해놓으면, 고민하는 시간이 줄어들지 않을까 생각해본다.
앞으로의 포스팅의 발전에 기대를 겁니다..! 아자아자💪