딱딱하다! SOLID!

maketheworldwise·2022년 3월 26일

Spring

나의 스프링 입문기 🚀

목록 보기

7/27

이 글의 목적?

객체 지향의 4대 특성을 이용한 객체 지향 설계 5원칙을 정리해보자.

간단하게 살펴보자

SRP(Single Responsibility Principle) : 단일 책임 원칙
OCP(Open Closed Principle) : 개방 폐쇄 원칙
LSP(Listov Substitution Principle) : 리스코프 치환 원칙
ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
DIP(Dependency Inversion Principle) : 의존 역전 원칙

SOLID는 응집도를 높이고 결합도를 낮추는 원칙이다.

💡 응집도와 결합도는 뭘까?

응집도는 한 모듈 내부의 처리 요소들이 서로 관련되어 있는 정도를 말한다. 즉, 모듈이 독립적인 기능을 수행하는지 또는 하나의 기능을 중심으로 책임이 잘 뭉쳐있는지를 의미한다.

결합도는 서로 다른 모듈 간에 상호 의존하는 정도 또는 연관된 관계를 의미한다. 자바에서 결합도가 높다는 의미는 해당 클래스와 다른 클래스와의 연관된 정도가 높다는 의미다. 따라서 해당 클래스를 변경하면 연관된 클래스도 변경해야하며 다른 코드에서 클래스를 재사용하기도 어렵다.

단일 책임 원칙

어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

하단의 이미지를 본다면, 남자 클래스가 수행해야하는 역할 및 책임이 많은 것을 알 수 있다. 즉, 하나의 클래스가 많은 역할과 책임을 가지고 있다. 이 구조에서의 문제점은, 남자 클래스에 의존하는 직장상사를 살펴보면, 사원 역할을 하는데 키스하기라는 행동은 불필요하다.

따라서 하단의 이미지처럼 남자라는 클래스를 각 역할에 맞게 잘 분리해주어야 한다.

단일 책임 원칙은 모델링 과정에서의 추상화와 관련이 있다. 애플리케이션 경계를 정하고 추상화를 통해 클래스들을 선별하고 속성과 메소드를 설계할 때 반드시 단일 책임 원칙을 고려하는 습관을 들여야한다.

개방 폐쇄 원칙

자신의 확장에는 열려있고 주변의 변화에 대해서는 닫혀 있어야 한다.

하단의 이미지를 보자. 운전자는 차종에 따라 행동이 달라지는데, 이러한 변화는 운전자에게 영향을 주기 때문에 문제가 발생한다.

하지만 상위 클래스 혹은 인터페이스를 중간에 두면, 다양한 자동차가 생긴다해도 운전자에게 큰 영향을 미치지 않도록 할 수 있다. 즉, 자동차의 확장에는 개방적이지만, 운전자는 차종이 어떤걸로 변경이 되어도 변화에 폐쇄되어있는 구조가 된다.

가장 대표적으로는 JDBC와 JVM이 있다. JDBC의 경우 DBMS가 변경되어도 연결 설정만 변경해주면 되고 자바 애플리케이션은 데이터베이스라는 주변 변화에 닫혀있어 이 원칙을 만족한다고 볼 수 있다.

리스코프 치환 원칙

is-a-kind-of / is-able-to 문장이 잘지켜져야한다.

인터페이스 분리 원칙

클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다.

단일 책임 원칙에서는 하나의 클래스를 작은 단위로 쪼개어 다수의 클래스로 분할하는 것이다. 인터페이스 분리 원칙은 다수의 클래스가 아닌 각 역할에 맞게 인터페이스로 분리하는 것을 의미한다. 결국, 단일 책임 원칙과 인터페이스 분리 원칙은 동일한 문제에 대한 두 가지 다른 해결책이다. 하지만 책에서는 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 했다.

최소주의 원칙

상위 클래스는 물려줄 특성이 풍성할 수록 좋고, 인터페이스는 구현을 강제할 메소드의 개수가 적을 수록 좋다.

상위 클래스가 풍성할 수록 좋은 이유는 하위 클래스에게 많은 기능을 확장시켜 형변환과 코드 중복을 줄여줄 수 있기 때문이고, 인터페이스가 구현을 강제할 메소드의 개수가 적으면 좋은 이유는 하위 클래스에게 구현을 강제하는 역할을 수행하기 때문에 최소한의 기능만 제공하여 하나의 역할에 집중할 수 있도록 하기 위해서다.