본문은 야곰 아카데미 커리어 스타터 캠프를 통해 학습한 내용을 회고한 글입니다.
SOLID 원칙
SOLID 원칙은 객체 지향 프로그래밍을 위한 다섯가지 기본 원칙이다.
이 원칙을 지킴으로써 유지보수가 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만들 수 있다.
| S(SRP) | 단일 책임 원칙 (Single responsibility principle) | 한 클래스는 하나의 책임만 가져야 한다. |
| O(OCP) | 개방-폐쇄 원칙 (Open/closed principle) | 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. |
| L(LSP) | 리스코프 치환 원칙 (Liskov substitution principle) | 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. |
| I(ISP) | 인터페이스 분리 원칙 (Interface segregation principle) | 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다 |
| D(DIP) | 의존관계 역전 원칙 (Dependency inversion principle) | 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. |
S: 단일 책임 원칙 (Single responsibility principle)
개념
한 클래스는 하나의 책임만 가져야 한다.
작성된 클래스가 하나의 기능만을 가지며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데에 집중되어한다는 원칙이다. SRP원칙을 적용하게 되면 책임의 영역이 확실히 분배가 된다. 그에 따라 1) 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있으며, 2) 코드의 가독성이 향상되고, 3) 코드를 유지보수하기가 용이해진다. 이는 객체지향 원리의 대전제 격인 OCP원칙(개방-폐쇄 원칙: Open/closed principle)뿐만 아니라 다른 원칙들을 적용하는 기초가 된다. SRP원칙을 통해 응집도는 높고 결합도는 낮은 코드를 작성하게 된다고 볼 수 있다.
O: 개방-폐쇄 원칙 (Open/closed principle)
개념
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
소프트웨어의 구성요소(클래스, 모듈, 함수 등)는 확장에 열려있고 변경에는 닫혀있어야한다는 원리이다. 이는 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화해야한다는 의미이다. 즉, 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야하며, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야한다는 뜻이다. 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다. 객체지향 원리의 대전제 격인 원칙이라고 볼 수 있다.
L: 리스코프 치환 원칙 (Liskov substitution principle)
개념
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
서브 클래스는 언제나 기반 클래스로 교체할 수 있어야한다는 것이다. 즉, 서브 클래스는 언제나 기반 클래스와 호환될 수 있어야한다는 말이다. 달리 말하면 서브 클래스는 기반 타입이 약속한 규약을 지켜야한다는 것이다. 그리고 자식 클래스는 부모 클래스의 동작을 바꾸지 않아야한다. 덧붙여 상속이 되었을 때, 서브 클래스는 기반 클래스대신 사용 되어도 같은 동작을 해야한다.
I: 인터페이스 분리 원칙 (Interface segregation principle)
개념
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
ISP원칙은 클래스에서 자신이 사용하지 않는 인터페이스는 구현하지 말아야한다는 원칙이다. 즉, 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야한다. 이를 '하나의 일반적인 인터페이스보다는 여러 개의 구체적인 인터페이스가 낫다’라고 정의할 수도 있다. SRP가 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조하는 셈이다. ISP를 통해 시스템 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게할 수 있다.
D: 의존관계 역전 원칙 (Dependency inversion principle)
개념
프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
DIP는 복잡한 컴포넌트간의 커뮤니케이션 관계를 단순화하기 위한 원칙이다. 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 역전시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. 첫째로 상위 모듈은 하위 모듈에 의존해서는 안 되고 상위 모듈과 하위 모듈 모두 추상화에 의존해야한다. 둘째로 추상화는 세부사항에 의존해서는 안 되고 구체적인 것이 추상화 된 것에 의존해야한다. DIP원칙은 상위와 하위 객체 모두가 동일한 추상화에 의존해야한다는 개체 지향적 설계의 대원칙을 따른다. DIP를 만족하면 의존성 주입이라는 기술로 변화를 쉽게 수용할 수 있다.
참조
'YAGOM CAREER STARTER' 카테고리의 다른 글
| [TIL] 20230130: foreach, compactMap (0) | 2023.01.31 |
|---|---|
| [TIL] 20230127: Type Properties (0) | 2023.01.28 |
| [TIL] 20230124: Generics (0) | 2023.01.26 |
| [TIL] 20230123: unit test, TDD, filter, reduce (0) | 2023.01.23 |
| [토요스터디A반] 20230121: UML을 바탕으로 코드 작성하기 (0) | 2023.01.23 |
