3. SOLID 원칙

1. 좋은 객체지향 프로그램을 만드는 방법

- 이전 포스팅에서 좋은 객체지향이란 다형성을 잘 유지하며 개발하는 것이라고 했다.

- 단순하게 역할과 구현을 분리하면 되는것 아닌가? 생각할 수 있다.

- 그러나 프로그램의 사이즈가 커질수록, 코드가 서로 얽히면서 객체지향을 유지하기 어려워진다. 

- 이처럼, 큰 규모의 프로그램에서도 좋은 객체지향 프로그래밍을 할 수 있도록 제시된 규칙이 있다.  

---

2. SOLID 원칙

a) 개요

- 클린 코드의 저자인 Robert Martin이 정리한 좋은 객체지향 프로그래밍의 5가지 원칙

- SOLID는 다섯가지 원칙의 앞글자를 따서 만들어진 이름이다.(SRP, OCP, LSP, ISP, DIP)

 

b) SRP(Single Responsibility Principle, 단일 책임 원칙)

- 하나의 클래스는 반드시 하나의 책임(= 역할)만 가져야한다는 원칙이다.

- 예를 들어, 객체의 생성과 사용을 분리하는 것, MVC를 분리하는 것 등이 있을 수 있다. 

 

c) OCP(Open-Close Principle, 개방-폐쇄 원칙 

- 프로그램의 확장에는 열려 있으나 변경에는 닫혀있다는 원칙

- 이는 다형성을 의미하는 것인데, 앞서 다형성 포스팅에서 client의 코드는 변경되지 않는다는 부분이 여기에 해당한다.

- 즉, 코드가 교체되어도 client는 이전과 동일한 방식으로 프로그램을 사용해야 한다는 의미다. 

 

- 과자만 파는 자판기가 음료를 파는 자판기로 변했다고 사용자가 새롭게 자판기 사용법을 익힐 필요가 없듯이

- 인터페이스를 기반으로 새로운 클래스나 객체의 생성을 통해 프로그램의 확장에는 열려있고

- 프로그램의 확장으로 인해 client의 코드를 수정하거나 변경할 필요가 없음을 의미한다. 

 

d) LSP(Liskov Substitution Principle, 리스코프 치환 원칙)

- 기존에 상위 타입 객체가 들어가는 자리에 하위 타입 객체를 사용해도 프로그램은 정상 작동해야 한다는 원칙

- ex) B가 A의 자식인 경우, A를 사용하는 메소드에 B를 넣어도 정상적으로 작동해야 된다.

 

- LSP 원칙을 지키기 위해서는 반드시 다음 규칙을 따라야 한다.

   → 인터페이스를 상속받아 클래스를 구현할 때, 상속받은 메소드는 본래의 목적대로 구현되어야 한다. 

 

ex) 인터페이스에 더하기 메소드가 있는데, 이를 상속받은 클래스가 로직의 내용을 빼기로 구현했다면 LSP를 위반한 것.

 

e) ISP(Interface Segregation Principle, 인터페이스 분리 원칙)

- 특정 client를 위한 인터페이스 여러 개가 모든 걸 포함하는 인터페이스 하나보다 낫다는 원칙

- 즉, 인터페이스가 다수의 역할을 구현하고 있으면 안된다는 의미 

 

ex) 운전자를 위한 인터페이스를 만드는데, 하나의 인터페이스가 운전과 정비에 대한 내용을 모두 담고있다면 ISP 위반이다.

 

f) DIP(Dependency Inversion Principle, 의존관계 역전 원칙)

- 프로그래머는 구현보다 추상화에 집중해야 한다는 원칙

- 구현체를 만드는 것에 집중하기보다 그 바탕이 되는 상위개념(ex. 인터페이스)을 잘 설계하는 것이 중요하다는 의미다.

 

- 다형성의 기본이 되는 원칙으로, 코드를 작성할 때 역할에 의존해야지 구현에 의존하면 안되는 것이다. 

- 이는 인터페이스 설계뿐만 아니라, 코드를 작성할 때에도 객체간의 의존성에도 적용되는 원칙이다.