객체 지향 설계 5원칙(SOLID) - 단일책임원칙SRP, 개방폐쇄원칙 OCP

객체지향 프로그래밍, 어떤 기준으로 설계하면 좋을까?

 

객체 지향 설계를 할 때, 시간이 지난 후에도 유지 보수와 확장이 쉬운 프로그래밍을 하기 위한 기본 원칙이 5개가 존재한다.

개발자라면 소프트웨어를 효율적이면서도 안전하고 정확하게 설계하고 싶을 것이다. 이 원칙들은 작성한 코드의 가독성을 높이고, 소프트웨어의 확장이 가능할 수 있도록 돕기 위해 필요한 전략이기도 하다.

 

여기서 이 5가지 원칙을 기억하기 쉽도록 각 약어의 맨 앞글자를 따서 SOLID 원칙으로 부르게 되었다.

단일 책임 원칙(SRP)

개방 폐쇄 원칙(OCP)

리스코프 치환 원칙(LSP)

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

의존관계 역전 원칙(DIP)

 

SRP, OCP, LSP, ISP, DIP  ==> SOLID

 

각 원칙이 무엇을 의미하는지, 간단하게 알아보자. 

 

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

- "하나의 객체는 하나의 책임(기능)만 가져야 한다."

어떤 클래스나 모듈을 변경할 경우, 그 이유는 단 하나 뿐이어야 한다. 이 원칙은 클래스의 적절한 크기를 가이드한다.

 

이 원칙을 무시한 상황에서 유지보수를 한다고 가정하자.

이 때 한 객체에 기능이 여러가지인 상황이 발생할 수 있는데, 이는 한 개의 클래스 내부가 복잡해지는 것을 의미한다.

 

예를 들어, A기능, B기능 C기능, 세 가지 기능을 가지고 있는 어떤 클래스는

각각의 기능이 각기 다른 이유로 수정을 요구를 받을 수 있을 것이다.

 

A기능 수정하면, B기능 C기능도 영향을 받을 수 있다. 이것은 유지보수하기에 나쁜 설계이다. 

그저, 한 가지 기능만 수정하려는 것 뿐인데 클래스를 통합하여(B기능, C기능도 정상 작동할 수 있도록) 코드를 수정해야하기 때문이다.

일종의 나비효과가 연쇄적으로 일어날 수 있는데, 상상만해도 벌써부터 머리가 지끈거릴 것이다.

 

만약 한 가지 클래스가 두 개 이상의 책임을 가지고 있다면, 이 책임을 분리하여 클래스를 작성하는 것이 옳을 것이다.

 

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

- "소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려있으나 변경에는 닫혀 있어야 한다."

즉, 소프트웨어의 기존 코드에 영향을 주지 않으면서, 새로운 기능이나 구성 요소를 추가할 수 있어야 한다는 의미이다.

 

이 원칙을 지키지 않는 상황을 가정해보자.

만약 새로운 기능이나 구성 요소를 추가하려는 행위가 기존 코드에 영향을 주도록 설계되어있다면, 영향을 받는 코드는 무엇이며, 어떤 영향을 미치는지 함께 파악하고 수정을 해야할 것이다. 이 경우, 기능 확장에 따르는 비용이 계속적으로 증가할 여지가 생긴다. 즉, 유지보수나 확장에 비효율적이다. 따라서 기존 코드를 변경하지 않으면서도 새로운 기능이나 구성 요소를 추가할 수 있도록 설계해야한다.

 

 

 

리스코프 치환원칙 LSP 알아보기  

https://veams.tistory.com/66

객체 지향 설계 5원칙(SOLID) - 리스코프 치환 원칙 LSP