좋은 소프트웨어 설계를 위해서는 결합도는 낮추고 응집도는 높여야 한다.
객체 지향 설계의 5원칙: SOLID
🌿SRP - 단일 책임 원칙
역할과 책임에 따라 클래스를 분리
예를 들어, 사람 클래스에 군번 속성이 있는데
남자는 반드시 군대를 가고 여자는 군대를 가지 않는다면?
강아지 클래스의 소변보기()메서드 내에서 암컷 수컷에 따라 분기 처리가 된다면?
단일 책임 원칙을 지키지 않은 것이다.
이런 분기 처리를 위한 if문은 단일 책임 원칙을 위배하고 있을 가능성이 있다.단일 책임 원칙을 지키기 위해서는 공통된 특성을 추상클래스의 추상메서드로 뽑아내고,
이를 extends하여 클래스를 정의해야 한다.
앞서 강아지 클래스의 경우는
암컷 강아지와 수컷 강아지가 각각 강아지 클래스를 extends하여 소변보다()를 구체화해야 한다.
🌿OCP - 개방 폐쇄 원칙
자신의 확장에는 열려 있고, 주변의 변화에는 닫혀 있어야 한다.
운전자 - 마티즈 => 운전자 - 소나타로 변경되면 운전자는 영향을 받는다.
하지만 운전자 -> 자동차로 상위 클래스 혹은 인터페이스를 두고, 소나타 혹은 마티즈로 세분화된다면 자신의 확장에는 개방되면서 주변의 변화에 영향을 받지 않는 (폐쇄된) OCP를 만족한다.
OCP의 가장 좋은 예시가 바로 JDBC이다.
JDBC를 사용하는 클라이언트는 JDBC인터페이스 덕에 DBMS종류가 바뀌어도 Connection을 수정할 필요가 없다.
스프링 프레임워크 역시 OCP의 좋은 예시다
🌿LSP - 리스코프 치환 원칙
상위 타입 객체를 하위 타입의 객체로 치환해도 문제 없이 동작해야 한다.
즉 하위 클래스의 인스턴스를 상위형 객체 참조 변수에 대입해서 상위 클래스 인스턴스 역할을 할 수 있어야 한다는 것
예를 들어,
public int eat(final Fruit fruit) {
return fruit.eat();
}
여기 파라미터에 fruit 대신 apple을 넘겨도 정상 동작해야 한다.
🌿ISP - 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다.
단일 책임 원칙과 같은 문제를 해결하기 위한 또 다른 방법이다.
남자 클래스와 여자친구, 어머니 등 각각의 클라이언트에 사이에 다른 인터페이스를 두는 것이다.
인터페이스를 통해 메소드를 외부에 제공할 때는 최소한의 메서드만 제공해야 한다.
상위 클래스는 최대한 풍부해야 한다. 빈약한 상위 클래스를 이용한 경우 여기저기 형변환이 발생하면서 상속의 혜택을 제대로 누리지 못한다.
일반적으로 단일 책임 원칙을 적용하는 것이 인터페이스 분리 원칙보다 나은 해결책이다.
🌿DIP - 의존 역전 원칙
고차원 모듈은 저차원 모듈에 의존하면 안 된다.
두 모듈 모두 추상화된 것에 의존해야 한다.
자동차 -> 스노우타이어 보다는
자동차 -> 타이어 (스노우타이어, 일반타이어, 광폭타이어)와 같이
여러 타이어들이 타이어 인터페이스를 상속한 형태로 바꾸면
기존의 변하기 쉬운 것에 의존하던 관계를, 추상화된 인터페이스를 추가하여 역전시킨다.
즉 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 영향을 받지 않게 하는 법칙이 바로
의존 역전 원칙이다.
