[OOP] S.O.L.I.D - 객체 지향 설계

이번 포스트에서는 S.O.L.I.D 에 대해 정리해볼 것이다.

 

참고

 

https://mangkyu.tistory.com/194

 

 

💡 SOLID란?

객체 지향 프로그래밍을 하면서 지켜야할 5가지 원칙. 앞글자들을 따서 S.O.L.I.D 이다.

 

1) SRP, Single Responsibility Principle

단일 책임의 원칙이란, 한 모듈이 하나의 액터, 즉, 한 종류의 서비스 로직을 수행할 수 있는 그룹에 대해서만 책임을 져야한다는 원칙이다. 

 

왜 SRP를 준수해야할까?

 

if 어떤 모듈이 여러 액터의 책임을 질 경우

→ 여러 액터들에 대한 변경 요구가 올 수 있기 때문에 해당 모듈이 변경되어야하는 이유도 여러가지가 됨

 

if 어떤 모듈이 한 액터의 책임만 질 경우

→ 한 액터에 대한 변경 요구만 책임지면 되기 때문에 해당 모듈이 변경되어야하는 이유도 한가지로 명확해짐

 

ex) 빗으로는 머리를 빗지만, 머리를 자르지는 않는다.

 

 

2) OCP, Open-Closed Principle

개방 폐쇄 원칙. 이름에서도 의미를 알 수 있다. 확장에 대해 열려있고, 수정에 대해 닫혀있다.

즉, 기존 로직을 수정하지 않으면서 새로운 요구사항에 대해 추가/변경할 수 있다.

 

Open? : 요구사항을 반영하여 새 로직을 추가해 애플리케이션 확장할 수 있음

→ 확장에 대해 열림!

 

Closed? : 기존 코드를 수정하지 않으면서 애플리케이션에 로직을 추가/변경 할 수 있음

→ 수정에 대해 닫힘!

 

개방 폐쇄 원칙을 지키기 위해서는 추상화에 의존해야함

 

→ 어떻게 추상화?

: 변하지 않는 부분은 고정, 변하는 부분만 변하는 부분 생략

 

→ 생략된 부분만 변경이 필요한 경우 수정하면 됨

 

ex) 요구 : 기존 디퓨저가 향은 좋은데, 패키지가 별로에요

수용 : 디퓨저 용액(향)은 고정하되, 패키지만 다른 디자인으로 바꿈

 

 

3) ISP, Interface segregation principle

인터페이스 분리 원칙이란, 목적과 관심이 다른 클라이언트들은 인터페이스로 적절히 분리하는 것이다.

 

즉, 클라이언트들을 목적과 용도에 맞게 사용하기 위해 그 목적과 용도에 맞는 인터페이스들을 분리해주는 것을 의미한다.

 

모든 클라이언트들이 그에 맞는 인터페이스들을 사용함으로써, 불필요한 간섭을 최소화할 수 있다.

 

ex) 떡순세트(떡볶이를 사면 순대를 줌)로 판매하는데 고객이 순대만 먹고싶다고 한다면?

→ 메뉴에 순대만 따로 추가할 것

 

 

4) LSP, Liskov Substitution Principle

리스코프 치환 원칙이란, 한 객체를 사용하는 클라이언트는 상위 타입이 하위 타입으로 변경되어도

상위 타입의 역할을 수행할 수 있어야한다는 것이다.

 

즉, 상위 타입의 public interface를 통해 서브 클래스 구현이 가능해야한다.

 

LSP에서 강조하는 부분

: 자식 클래스가 부모 클래스를 대체하기 위해서는 해당 객체를 사용하는 클라이언트의 가정을 준수해야한다

 

ex) 기존 폰에 있던 메모장 말고 다른 메모장 앱을 다운로드 받아서 사용하려고 할 때

→ 사용자는 기존 폰에 있던 메모장의 메모 기능을 수행할 수 있는 메모장 앱을 선택할 것임

→ 메모장 앱은 메모 기능을 수행해야함

 

 

5) DIP, Dependency Inversion Principle

의존 역전 원칙이란, 비지니스와 관련된 입력과 출력으로부터 거리가 먼 추상화된 모듈은 입력과 출력으로부터 거리가 가까운 HTTP, DB 등과 관련된 구현 모듈에 의존해서는 안되고, 그 반대가 되어야한다는 것이다.

 

→ 비지니스 관련 사항이 세부 사항에 의존하지 않음!

 

의존이 역전되는 시점?

: Compile

 

ex) 자동차는 엔진이 필요하고, 엔진에는 여러 종류가 있음

→ 자동차는 엔진에만 의존하고, 그 엔진의 종류에는 의존하지 않음

→ 자동차는 남기고 엔진만 언제든지 교체 가능!

 

 

💡 SOLID 원칙을 따르면 좋아지는 이유에 대한 개인적인 의견

 

• 단일 책임의 원칙을 따름으로써 어떠한 로직을 추가하거나 변경할 때 모든 로직을 건드리지 않고 그 액터의 기능을 수행하는 모듈만 추가/수정함으로써 요구사항을 반영할 때 대응하는 것이 쉬워질 것

 

• 개방-폐쇄의 원칙을 따르며 추상화를 통해 변하지 않는 부분은 고정하고 변하는 부분만 남김으로써 변하지 않는 부분에는 손을 대지 않고 변하는 부분만 수정해 애플리케이션을 수정할 수 있음

 

• 인터페이스 분리 원칙을 따름으로써 클라이언트의 목적에 대한 요구사항에 적합한 인터페이스만을 제공할 수 있다는 점에서, 클라이언트가 인터페이스에 대한 불필요한 간섭을 최소화할 수 있고 기존 클라이언트에도 영향을 주지 않는다는 점에서 유연하게 대응할 수 있음

 

• 리스코프 치환 원칙을 수행함으로써 부모 클래스의 동작을 기반으로 코드를 작성했을 때, 어떤 자식 클래스를 사용하더라도 예상하지 못한 버그 없이 동일하게 작동함을 보장할 수 있음

 

• 의존 역전 원칙을 지키면 상위 기능과 하위 기능 사이의 결합도가 낮아지므로 특정한 어떤 것에 종속되지 않고, 필요에 따라 다양한 종류로 교체할 수 있어 시스템이 유연해짐

 

 

 

감사합니다 (。・ω・。)