Backend/Spring

[Spring] 객체 지향과 SOLID 원칙

JOYERIM 2023. 7. 4. 13:36

 

 

이번 게시물에서는 SOLID 원칙에 대해 정말 찍먹으로 다루고자 한다.

 

추후 읽을 예정인 Clean Code의 저자 로버트 C. 마틴이 2000년대 초반 객체 지향 설계의 다섯 가지 기본 원칙으로 제시한 것이 SOLID 원칙이다.

 

생각해보면 결국 스프링 또한 객체 지향을 지키기 위한 하나의 수단일 뿐이다. High Cohesion - Loose Coupling을 이루기 위한 방법과 스프링은 SOLID 원칙을 어떤 방식으로 설계하여 지키고자 하였는지 알아볼 생각에 설렐 뿐 .. 

 

그러기 위해 SOLID 원칙에 대해 먼저 알아보도록 하자.

 

 

 

 

 

 

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

 

 

 

 

SPR(단일 책임 원칙: Single Responsibility Principle)
"한 클래스는 하나의 책임만 가져야 한다."

 

 

단일 책임 원칙은 클래스(객체)는 단 하나의 책임만 가져야 한다는 원칙이다. 이때 '책임'은 하나의 '기능'으로 보면 된다. 책임이라는 게 모호하기 때문에 기준이 정해진 것은 아니나, 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것으로 생각할 수 있다.

 

 

 

 

 

OCP(개방-폐쇄 원칙: Open/Closed Principle)
"소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 한다."

 

 

 

SOLID 원칙 중에서 가장 중요하면서도 객체 지향의 근간이다.

 

클라이언트는 대상의 역할(인터페이스)만 알면 되고, 구현 대상의 내부 구조를 몰라도 된다.

즉, 클라이언트는 구현 대상의 내부 구조가 변경되거나 대상 자체를 변경하여도 영향을 받지 않는다.

 

핵심은 역할(인터페이스)과 구현(인터페이스를 구현한 클래스, 구현 객체)의 분리 !

 

 

 

 

 

LSP(리스코프 치환 원칙: Liskov Substitution Principle)
"프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다."

 

LSP 원칙은 다형성을 지키기 위한 원칙으로, 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다. 그 예시로 Collection 프레임워크가 있다.

 

 

 

 

 

 

ISP(인터페이스 분리 원칙: Interface Segregation Principle)
"특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다."

 

아래 예시로 설명을 하자면, 자동차 인터페이스는 운전 인터페이스, 정비 인터페이스로 분리한다. 또한 사용자 클라이언트는 운전자 클라이언트와 정비사 클라이언트로 분리한다.

 

이렇게 분리할 경우, 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않는다.

 

즉, 인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

 

 

 

 

 

DIP(의존관계 역전 원칙: Dependency Inversion Principle)
"프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나다."

 

 

 

쉽게 말하면, 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻이다. 앞에서 다뤘듯, 역할에 의존하게 해야 한다는 말이다.