SOLID 원칙
OOP를 하며 따르기 위한 5가지 개발 원칙.
항상 지켜져야 하는 것은 아님.
Robert C. Martin에 의해 만들어짐. (또 이 아저씨..)
S - Single Responsibility (단일 책임)
하나의 객체는 한가지 책임만 가지고 있어야 한다.
만약 하나의 객체가 여러가지의 책임 또는 역할을 가지고 있는 경우,
책임 중 하나의 코드를 변경하면 자기자신도 모르게 다른 것들에 영향을 줄 수 있으므로 버그 가능성이 높아짐.
핵심
변경으로 인해 버그가 발생하더라도 다른 동작에 영향을 미치지 않도록 분리하는 것.
O - Oepn-Closed (개방-폐쇄)
객체는 확장에는 열려있어야 하지만 수정에는 닫혀있어야 한다.
객체를 변경하게 되면 해당 객체를 사용하는 모든 곳에 영향을 끼친다.
그러므로 만약 객체에 기능을 추가하려면 이미 존재하는 것은 변경하지 않고 새로 추가하는 것이다.
핵심
객체의 기존 동작을 변경하지 않고 객체의 기능을 확장하는 것.
객체가 사용되는 모든 곳에서 버그가 발생하지 않도록 하기 위한 것이다.
L - Liskov Substitution (리스코프 치환)
A가 부모, B가 자식인 경우, A 타입이 필요한 상황에서 B가 대체할 수 있다.
자식이 부모와 동일한 작업을 할 수 없다면 버그가 발생할 수 있다.
상속을 받는다면 부모가 할 수 있는 일을 자식이 모두 할 수 있어야 한다.
그림의 상황에서는 Sam이 배달하는 커피와 Eden이 배달하는 카푸치노는 같은 커피 유형이기때문에 가능하지만
물은 커피유형이 아니기 때문에 불가능하다.
만약 요구사항을 충족하지 않는다면(커피가 아니라 물을 배달하는것으로 바뀌었다면) 자식 객체가 완전히 변경되어 원칙에 위배됨을 의미한다.
핵심
부모와 자식 객체가 모두 오류없이 동일한 방식으로 사용될 수 있도록 일관성을 유지하는 것
I — Interface Segregation (인터페이스 분리)
객체가 필요하지 않은 기능까지 구현해야 하거나, 어떤 기능을 가지고 있지 않으면 버그가 발생할 수 있다.
객체는 어떤 역할을 하는데 필요한 메서드만 가지고 있어야 한다.
다른 메서드들은 제거하거나 다른 곳으로 옮겨야 한다.
핵심
객체가 필요한 작업만 가지고 있도록 어떤 작업을 작은 집합으로 분할하는 것.
D — Dependency Inversion (의존성 역전)
고수준 모듈은 저수준 모듈에 의존하면 안된다.
둘 다 추상화에 의존해야 한다.
추상화는 세부사항에 의존해서는 안된다.
세부사항이 추상화에 의존한다.
고수준 모듈: 저수준의 모듈로 작업을 실행하는 클래스
저수준 모듈: 작업을 실행하는데 필요한 도구
추상화: 두 객체를 연결하는 인터페이스
세부사항: 도구 작동 방식
로봇(고수준 모듈)은 피자커터(저수준 모듈)에 의존하면 안된다.
어떤 Tool 이라는 추상화에 의존해야한다. (어떤 Tool을 채택한 객체가 오던 작업을 할 수 있도록)
객체와 인터페이스가 모두 도구가 작동하는 방식을 몰라야 한다.
하지만 도구는 인터페이스가 요구하는 기능을 충족해야한다.
핵심
하위 객체(도구)에 대한 상위 객체(로봇)의 종속성을 줄이는 것
정리
SRP - 객체가 하나의 역할만
OCP - 객체를 수정하지말고 확장해라
LSP - 자식이 부모를 대체할 수 있어야 한다.
ISP - 인터페이스 SRP
DIP - 객체가 필요하면 추상화해라
출처: https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898
The S.O.L.I.D Principles in Pictures
If you are familiar with Object-Oriented Programming, then you’ve probably heard about the SOLID principles.
medium.com