응집도와 결합도

  • 좋은 소프트웨어 설계를 위해서는 결합도는 낮추고 응집도는 높여야 한다.
  • 결합도
    • 모듈(클래스)간의 상호 의존 정도를 나타내는 지표로써 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용 및 유지보수가 유리하다.
  • 응집도
    • 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용 및 유지보수가 용이하다.

단일 책임 원칙, Single Responsibility Principle

  • 하나의 클래스는 하나의 책임만 가져야한다.
  • 책임이란 기준이 모호하기 때문에 변경을 책임의 기준으로 삼으면 설계에 용이할 수 있다.
  • 어떠한 역할에 대해 변경사항이 발생했을때 영향을 받는 기능만 모아둔 클래스라면 동일한 책임을 지닌 기능이 모인 집합으로써 SRP원칙이 적용된 설꼐로 볼 수 있을 것 같다.
  • 이처럼 변경사항이 있을때 애플리케이션의 파급 효과가 적으면 SRP원칙을 잘 따른것으로 볼 수 있다.


개방 폐쇄 원칙, Open Closed Principle

  • 높은 응집도
    • 응집도가 높다는건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻이다. 같은 책임 관심사를 기반으로 하나의 객체로 설계하기 때문에 객체에 변경이 발생하더라도 다른 곳에 미치는 영향이 제한적이다.
  • 낮은 결합도
    • 책임과 관심사가 다른 객체 또는 모듈과는 낮은 결합도를 유지해야 한다. 이는 높은 응집도 보가 더 민감한 원칙이다.
    • 결합도란 하나의 오브젝트가 변경이 일어날때 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도로 설명한다.
    • 낮은 결합도란 하나의 변경이 발생할 때 다른 모듈과 객체로 변경에 대한 요구가 전파되지 않는 상태라고 할 수 있다.


리스코프 치환 원칙, Liskov Substitution Principle

  • 객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.
  • 하위 클래스는 인터페이스 규약을 지켜서 작성되어야 하낟. 다형성을 지원하기 위한 원칙,인터페이스를 구현한 구현체는 믿고 사용하려면 LSP가 필요하다.
  • 인터페이스의 메소드를 사용한다고 하면 어떤 구현체를 사용하든 호출부에서 기대하는대로 동작되어야 한다는 것이다.
interface Calculator{
   int add(int num1, int num2);
}
  • 호출부에서 add()를 호출하면 내부 로직을 모르더라도 파라미터에 들어온 데이터를 합산해서 반환해줄것이라는 것을 기대하고 사용할테니 인터페이스 Calculator의 구현체 하위 클래스들은 이런 규약을 지켜서 설계되어야 한다.


인터페이스 분리 원칙, Interface Segragation Principle

  • 범용 인터페이스 하나보다는 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다고 한다.
  • 운전자가 자동차를 운전한다. 라는 명제를 객체간 관계로 비유하면 자동차에 대한 인터페이스 운전자에 대한 인터페이스를 각각 분리하는 것이다.
  • 그럼 운전자는 택시기사가 될수도 있고 우버 드라이버가 될 수 있다. 자동차는 버스가 될 수도 있고 택시가 될 수도 있고 스포츠카가 될 수도 있다. 확장성이 커지는 셈이다.


의존관계 역전 원칙, Dependency Inversion Principle

  • 프로그래머는 구체화가 아니라 추상화에 의존해야 한다고 한다.
  • 구현 클래스가 아니라 인터페이스에 의존하라는 이야기이다.
  • 연극을 예로 들면 배역(인터페이스) 과 배우(구현체) 를 예로 들 수 있다. 이 때 연극은 특정 배우를 염두에 두고 기획되기보다 배역에 집중해서 기획되어야 한다.
  • 특정 배우에 의존했는데 만약 그 배우가 스케줄 또는 당인 컨디션때문에 연극에 출연이 불발 될 경우 해당연극은 차질이 불가피해진다. 따라서 연극은 배우가 아닌 배역에 의존해야 한다.

Leave a comment