좋은 객체지향의 5가지 원리 - SOLID

좋은 설계란?

시스템에 새로운 요구사항이나 변경사항이 있을 때 영향을 받는 범위가 적은 구조
 

SOLID란?

객체지향 설계에서 지켜줘야할 SW개발 원칙 5가지의 앞글자를 딴 것
1) SPR (Single Responsibility Principle) : 단일 책임 원칙
2) OCP (Open Closed Principle) : 개방 폐쇄 원칙
3) LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
4) ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
5) DIP (Dependency Inversion Principle) : 의존 역전 원칙
 
SOLID는 프레임워크 X, 라이브러리 X, 디자인패턴 X, 특정기술에 국한되지도 않음
TypeScript나 Java와 같이 선호하는 프로그래밍 언어나 프레임워크 원칙에 자유롭게 적용 가능
웬만한 언어는 객체지향 프로그래밍을 지원하므로 이론 원칙을 그대로 적용 가능

SOLID 객체지향 원칙을 적용하면?

- 코드를 확장하고 유지보수 관리가 쉬워짐
- 불필요한 복잡성을 제거해 리팩토링에 소요되는 시간 줄임
- 프로젝트 개발의 생산성 높일 수 있음
 

1) SPR (Single Responsibility Principle) : 단일 책임 원칙

클래스(객체)는 단 하나의 책임만 가져야 한다

- '책임'이라는 의미는 하나의 '기능 담당'으로 보면 됨

- 만약 하나의 클래스에 여러 개의 기능이 있다면 기능 변경사항이 생겼을 때 수정해야할 코드가 많아짐
- 따라서 하나의 클래스는 하나의 기능을 담당하여 하나의 책임을 수행하는데 집중해야 함
 

2) OCP (Open Closed Principle) : 개방 폐쇄 원칙

확장에 열려있어야 하며, 수정에는 닫혀있어야 한다
- 기능 추가 요청이 오면 클래스를 '확장'을 통해 손쉽게 구현, 확장에 따른 클래스 '수정'은 최소화
-  OCP 원칙은 추상화와 상속을 통한 관계 구축 권장
- 다형성과 확장을 가능케 하는 객체지향의 장점을 극대화
[확장에 열려있다] : 새로운 변경사항 발생 시 유연하게 코드 추가 
[변경에 닫혀있다] : 새로운 변경사항 발생 시 객체를 직접적으로 수정하는 것을 제한
 
< OOP의 4가지 특징 >

OOP = Object-Oriented Programming = 객체지향 프로그래밍
1) 추상화 : 복잡한 시스템에서 불필요한 세부사항을 숨기고 필요한 핵심 기능만 노출
ex) 자동차 운전하는 사람은 핸들, 브레이크 같은 중요한 제어장치만 사용
자동차의 내부엔진, 연료시스템 등 복잡한 기술적 세부사항 알 필요 없음
 
2) 상속 : 부모클래스의 변수와 메서드를 자식클래스가 물려받아 재사용
ex) Animal 클래스가 Dog 클래스에게 기본 속성 물려줌
 
3) 다형성 : 메서드 이름은 같지만 객체의 종류에 따라 다르게 동작
ex) 메서드 오버로딩(같은 이름, 다른 파라미터)
ex) 메서드 오버라이딩(자식클래스에서 부모클래스의 메서드 덮어쓰기)
-> Animal 클래스의 makeSound() 메서드를 Dog 클래스에서는 "멍멍", Cat 클래스에서는 "야옹"이라고 구현
 
4) 캡슐화 : 객체 내부 구현을 숨기고 외부와의 상호작용은 메서드를 사용
ex) 은행계좌 클래스에서 계좌 잔액은 외부에서 직접 변경할 수 없도록 private으로 설정
대신 입출금을 처리할 수 있는 공개된 메서드들만 외부에 제공하여 계좌상태를 안전하게 관리

 

3) LSP (Liskov Substitution Principle) : 리스코프 치환 원칙

서브타입은 언제나 기반(부모)타입으로 교체할 수 있어야 한다
- 자식클래스는 최소한 자신의 부모클래스에서 가능한 행위는 수행이 보장되어야 함
- 부모클래스의 인스턴스를 사용하는 위치에 자식클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 작동해야함
- 부모 메서드의 오버라이딩을 조심스럽게 따져가며 해야함
- 자식클래스가 부모클래스의 기존 동작을 변경하거나 예외를 발생시키지 않도록 해야 함
- 다형성의 원리를 이용하기 위한 원칙
 

4) ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

인터페이스를 각각 사용에 맞게 잘게 분리해야 한다
- SPR 원칙이 '클래스'의 단일 책임을 강조한다면, ISP는 '인터페이스' 단일책임을 강조함
- 인터페이스는 제약 없이 자유롭게 다중상속이 가능하므로, 분리할 수 있으면 다 분리하여 각 클래스 용도에 맞게 implement하라는 설계 원칙
- 한 번 인터페이스를 분리하여 구성해놓고 나중에 수정사항이 생겨서 또 인터페이스를 분리하는 행위를 가하지 말아야 함
- 인터페이스는 한 번 구성했으면 웬만해서 변하면 안되는 정책 개념
 
* 인터페이스란?
객체지향 프로그래밍에서 클래스가 구현해야할 메서드들의 집합을 정의하는 계약
객체지향에서 인터페이스는 구체적인 구현을 제공하지 않고, 어떤 메서드가 존재할 것인지만 정의함
-> 인터페이스를 구현하는 클래스가 이 메서드를 구체적으로 구현해야 함
 

5) DIP (Dependency Inversion Principle) : 의존 역전 원칙

어떤 클래스를 참조해서 사용해야하는 상황이 생긴다면, 그 클래스를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상클래스 또는 인터페이스)를 참조해야 한다 
- 구현된 클래스에 의존하지 말고 인터페이스에 의존하라는 의미
- 의존관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는, 변화하기 어려운 것 또는 변화가 거의 없는 것에 의존해야 함
- 의존 역전 원칙의 지향점은 각 클래스 간의 결합도를 낮추는 것
 

 
 
참고자료 출처 : https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID

💠 객체 지향 설계의 5가지 원칙 - S.O.L.I.D