좋은 소프트웨어 설계를 위해선 결합도는 낮추고 응집도는 높여야 한다.
- 결합도 : 클래스간의 상호 의존 정도를 나타내는 지표. 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용 및 유지보수가 유리하다.
ex) A 클래스가 B 클래스를 B 클래스가 C 클래스를 의존하면 결합도가 높다. 만약 A클래스를 수정하면 B,C 클래스를 수정해야 한다.- 응집도 : 하나의 클래스 내부에 존재하는 구성 요소들이 기능적 관련성으로 응집되어 있어야 된다.
1. SRP 단일 책임원칙
어떠한 클래스를 변경해야 하는 이유는 한가지 뿐이여야 한다.
하나의 클라이언트가 너무 많은 기능을 가지고 있어서 단일 책임 원칙으로 분리를 해야한다.
Netword 하는 기능들 따로 빼고 File Reader() 클래스도 따로 분리해서 응집도를 높인다.
public class Unit {
private String name;
private int speed;
public void attack(){
}
public void move(){
if(name.equals("저글링")) speed += 3;
else if(name.equals("탱크")) speed += 5;
else if(name.equals("옵저버")) speed += 15;
}
}위 코드를 보면 유닛이 추가될 때마다 else if 100번 써야 한다. 그리고 수정이 일어나면 찾아야 된다.
매우 비효율적이다. 단일책임과 다형성을 줌으로써 객체지향 설계를 해보자.
public class Unit{
String name;
int speed;
public void attack(){
}
public void move(){
}
}
public class Protoss extends Unit{
public void move(){
this.speed += 5 ;
}
}
public class Terran extends Unit{
public void move(){
this.speed += 4;
}
}프로토스, 테란, 클래스를 만들어서 유닛으로부터 move 오버라이딩 한다.
move라는 메서드만 호출해서 각각 객체의 기능을 정의한대로 동작을 한다.
단일 책임 원칙으로써 프로토스는 프로토스 기능, 테란은 테란 기능만 하게 된다.
2. OCP : 개방 폐쇄 원칙
자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다.
상위 클래스 또는 인터페이스를 중간에 둠으로서, 자신은 변화에 대해서는 폐쇄적이지만,
인터페이스는 외부의 변화에 대해서 확장을 개방해 줄 수 있다.
어플리케이션 입장에선 외부적으로는 DB가 많다. 그래서 직접 연결하면 App 내의 코드가 변경되어야 하기에 JDBC 인터페이스를 둬서 외부 DB가 뭐가 추가되던 상관 없이 JDBC 인터페이스를 통해 내부적으로는 단 하나의 통로를 가지고 밖으로는 N개의 개방적으로 확장된 부분이 개방 폐쇄 원칙을 잘 지킨 예시라 볼 수 있다.
3. LSP : 리스코프 치환 원칙
서브 타입은 언제나 자신의 기반(상위) 타입으로 교체할 수 있어야 한다.
ex)하위 타입이 상위 타입으로 언제나 교체될 수 있어야 원칙을 잘 지켰다 할 수 있다.
4. ISP : 인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.
프로젝트 요구 사항과 설계에 따라 SRP(단일책임원칙) / ISP(인터페이스 분리원칙) 를 선택한다.
ex) 지도 객체는 다양한 안내가 있다. 그러나 자동차 내비면 자동차 길 안내만 있으면 되는데
굳이 지도를 상속받아서 다양한 안내 메서드가 있을 필요가 없다.
그래서 인터페이스를 분리시켜서 자전거 길 안내, 자동차 길 안내 등, 자전거 내비는 자전거 길 안내 인터페이스를 구현함으로써 자전거 내비는 자전거 길 안내만 하는게 인터페이스 분리 원칙이다.
5. DIP : 의존 역전 언칙
자신보다 변하기 쉬운 것에 의존하지 말아야 한다.
사람은 옷에 의존하는데 옷은 계절에 따라 변하기 마련이다.
그럼 옷 인터페이스를 만들어서 사람은 옷에 의존을 하면 된다.
