SOLID란 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙이다.
프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다.
SOLID의 다섯 가지 원칙은 아래와 같다.
- 단일 책임 원칙(Single responsibility principle)
- 계방-폐쇄 원칙(Open/closed principle)
*리스코프 치환 원칙 (Liskov substitution principle) - 인터페이스 분리 원칙 (Interface segregation principle)
- 의존관계 역전 원칙 (Dependency inversion principle)
우선은 첫 번째 원칙인 단일 책임에 관해서만 다뤄보겠다.
1. 단일 책임 원칙(Single responsibility principle)
1-1. 한 클래스는 하나의 책임만 가져야 한다.
- 책임에는 두 가지가 있다.
- Knowing은 객체가 알아야 하는 데이터
- Doing은 객체가 해야하는 일
1-2. 응집도를 높이는 방향이다. (결합도와는 상반되는 개념)
1-3. 클래스의 변경 이유는 하나여야 한다.
- 결합도가 높을 경우, 동일한 변경 이유가 여러 클래스에서 발생할 수 있다.
2. 계방-폐쇄 원칙(Open/closed principle)
2-1. 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 요구사항이 변경되거나 추가되어도 기존 요소는 수정되지 않고, 이 기존 요소는 쉽게 확장되어 재사용성이 확보되어야 한다.
- 김밥 장사를 위해 김밥을 추상화한다면
- 단순히 야채김밥만 객체화될 때에 비해, 김밥의 종류 추가 비용을 최소화할 수 있을 것이다.
- 하지만 이 추상화가 지나치게 구체적일 경우, 되려 추가사항에 대응할 수 없어지기 때문에 주의해야 한다.
- 김밥 장사를 위해 김밥을 추상화한다면
일반화와 추상화가 일치하는 개념이 아니라는 걸 상기하자.
참고링크
다루지 못한 원칙들
-
리스코프 치환 원칙 (Liskov substitution principle)
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. -
인터페이스 분리 원칙 (Interface segregation principle)
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. -
의존관계 역전 원칙 (Dependency inversion principle)
프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다
