SOLID 원칙

컴퓨터 프로그래밍에서 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

- 이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부가 된다.

 

두문자	약어	개념
S	SRP	단일 책임 원칙(Single responsibility principle)
O	OCP	개방-폐쇄 원칙(Open/closed principle)
L	LSP	리스코프 치환 원칙(Liskov substitution principle)
I	ISP	인터페이스 분리 원칙(Interface segregation principle)
D	DIP	의존관계 역전 원칙(Dependency inversion principle)

 

---

단일 책임 원칙 SRP(Single responsibility principle)

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다.

 로버트 마틴은 어떤 클래스나 모듈은 변경하려는 단 하나의 이유만을 가져야 한다고 결론지었다. 예를 들어서 보고서를 편집하고 출력하는 모듈을 생각해보자. 이 모듈은 두 가지 이유로 변경될 수 있다. 첫 번째로 보고서의 내용 때문에 변경될 수 있다. 두 번째로 보고서의 형식 때문에 변경될 수 있다. 이 두 가지 변경은 하나는 실질적이고 다른 하나는 꾸미기 위한 매우 다른 원인에 기인한다. 단일 책임 원칙에 의하면 이 문제의 두 측면이 실제로 분리된 두 책임 때문이며, 따라서 분리된 클래스나 모듈로 나누어야 한다. 다른 시기에 다른 이유로 변경되어야 하는 두 가지를 묶는 것은 나쁜 설계일 수 있다.

 

---

개방-폐쇄 원칙 OCP(Open/Closed principle)

소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다 라는 프로그래밍 원칙이다.

 만약 한 가지 모듈을 수정할 때 그 모듈을 이용하는 다른 모듈을 줄줄이 고쳐야 한다면, 이와 같은 프로그램은 수정하기가 어렵다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 리펙토링 하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다.

 

문제점

• 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없는 경우가 있다.
• 이 문제를 해결하는데 Spring이 많은 도움을 준다. (객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다)

추상화를 통한 개방-폐쇄 원칙

추상화된 소프트웨어 개체는 수정에 대해 닫혀 있을 수 있고, 반대로 추상화의 새 파생 클래스를 만드는 것을 통해 확장이 가능하다. 추상화는 개방-폐쇄 원칙의 핵심 요소이다.

객체 지향 언어와 개방-폐쇄 원칙의 관계

개방-폐쇄 원칙을 무시하고 프로그래밍을 한다면, 객체 지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성 등을 결코 얻을 수 없다. 객체 지향 프로그래밍 언어에서 개방-폐쇄 원칙은 반드시 지켜야 할 기본적인 원칙이다.

 

---

리스코프 치환 원칙 LSP(Liskov substitution principle)

치환성은 객체 지향 프로그래밍 원칙이다. 컴퓨터 프로그램에서 자료형 S가 자료형 T의 하위형이라면 필요한 프로그램의 속성의 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체할 수 있어야 한다는 원칙이다. 그런데 리스코프 치환 원칙은 단순히 컴파일에 성공하는 것을 넘어서는 이야기이다. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙이다. 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.

 

• 하위 자료형의 분류는 상위 자료형의 한 종류이다.
• 구현 분류는 인터페이스 화할 수 있어야 한다.

즉, 하위 자료형의 인스턴스는 상위 자료형에 대입해 상위 자료형의 인스턴스 역할을 하는데 문제가 없어야 한다.

 

---

인터페이스 분리 원칙 ISP(Interface segregation principle)

인터페이스 분리 원칙은 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 한다. 이와 같은 작은 단위들을 역할 인터페이스라고도 부른다. 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리펙토링, 수정, 재배포를 쉽게 할 수 있다.

 

결록적으로 단일 책임 원칙(SRP)와 인터페이스 분리 원칙(ISP)은 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다. 하지만 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것을 우선한다.

 

상위 클래스는 풍성할수록 좋다.
풍성할수록 하위 클래스에게 많은 기능을 확장시켜주는 것이고, 형 변환, 코드 중복을 줄여준다.

인터페이스 내에 메서드는 최소한일수록 좋다.
인터페이스는 하위 클래스에게 구현을 강제하도록 하는 역할이다. 즉 최소한의 기능만 제공하면서 하나의 역할에 집중하라는 뜻이다.

 

---

의존관계 역전 원칙 DIP(Dependency inversion principle)

객체 지향 프로그래밍에서 의존관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다. 이 원칙을 따르면, 상위 계층이 하위 계층에 의존하는 전통적인 의존 관계를 반전(역전) 시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. 

1. 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
2. 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다. 

이 원칙은 상위와 하위 객체 모두가 동일한 추상화에 의존해야 한다는 객체 지향적 설계의 대 원칙을 제공한다.

 

예를 들어 많은 라이브러리들이 DIP를 활용하는데 우리는 라이브러리 구현체의 변경사항에 신경 쓰지 않고 편하게 추상화된 메서드만을 사용할 수 있다. 

 

아래 코드에 MemberService가 DIP를 지키고 있는지 생각해보자.

public class MemberService {
    private MemberRepository memberRepository = new MemoryMemberRepository();
}

OCP 원칙에서 말하는대로 MemberService는 인터페이스에 의존하지만, 문제는 구현 클래스에도 동시에 의존한다는 것이다. MemberService 클라이언트가 구현 클래스를 직접 선택하는 것도 문제이다. 즉 DIP를 위반하고 있다.

 

---

정리

• 객체 지향의 핵심은 다형성
• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성 만으로는 OCP, DIP를 지킬 수 없다.
• 뭔가 더 필요하다 !!

---

reference

https://ko.wikipedia.org/wiki/SOLID_(% EA% B0% 9D% EC% B2% B4_%EC% A7%80% ED%96% A5_%EC%84% A4% EA% B3%84) 

SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전

https://www.inflearn.com/course/스프링-핵심-원리-기본편/

스프링 핵심 원리 - 기본편 - 인프런 | 강의