SOLID 원칙

객체지향을 올바르게 적용할 수 있는 설계 원칙 5가지에 대해 정리하겠습니다.

 

SOLID

 

1. SRP(단일 책임 원칙, 분류)

한 클래스는 하나의 책임만을 가져야 합니다.

처음, 클래스는 가벼운 책임들만을 가집니다.

하지만 연차가 쌓이고 서비스가 수정되어 나가면서 한 클래스가 너무 많은 기능을 담당하게 됩니다.

이럴 때는 클래스를 분리시켜서 가능하다면 한 가지의 책임 혹은 일부의 기능만을 수행하는 클래스를 만들어야 합니다.

 

컨플릭을 방지, 역할에 해당하는 서비스를 잘 찾을 수 있습니다.

2. OCP(개방 폐쇄 원칙, 교체)

클래스를 수정하지 않고 확장하라는 의미 입니다.

각 메서드에서 반복적인 if ~ else 구조가 보이게 된다면 클래스 분리를 고려하여

인터페이스를 만들고 각각의 구현체 클래스를 만들어서 확장시키면 됩니다.

 

if ~ else에서 반복적인 케이스가 보이면 클래스 분리를 고려해야 합니다.

3. LSP(리스코프 치환 법칙, 교체)

상속받은 클래스는 부모 클래스와 동일한 동작을 해야 재활용 가능성이 높아집니다.

• 인터페이스가 아닌 상속을 사용하게 될 경우 오버라이딩 해야할 메서드를 빼먹는 fragile base class 문제가 발생할 수 있습니다.

상속보다는 IF를 고려하고 상속을 해도 비슷하게 만들어야 교체가 쉽습니다.

4. ISP(인터페이스 분리 원칙, 분류)

한 인터페이스에 너무 많은 기능을 넣게 된다면 구현체에서 구현하지 않아도 되는 빈 메서드를 구현해야하는 문제가 생깁니다.

이를 방지하기 위해 하나의 인터페이스를 더 작은 단위로 쪼갤 필요가 있습니다.

 

인터페이스도 SRP를 따라야 구현이 편리하고 재활용성이 올라갑니다.

5. DIP(의존성 역전 원칙, 교체)

상위 모듈이 하위 모듈에게 의존이 아닌 하위 모듈이 상위 모듈에게 의존하도록 변경한다면

하위 모듈이 바뀌어도 상위 모듈에는 영향이 가지 않습니다.

직접적으로 클래스를 바라보도록 하지 않고 인터페이스를 만들어 구현체 클래스를 만들도록 한다면

클래스가 변경되어도 인터페이스에는 영향이 가지 않기 때문에 좋은 설계라 할 수 있습니다.

 

하위 모듈에 너무 의존하면 변경이 어렵습니다. 중간 IF를 둬야 하위 모듈 변경이 쉽습니다.