SOLID 원칙이란?
- 객체 지향 프로그래밍에서 코드 품질을 높이고 유지보수를 용이하게 하기 위한 다섯 가지 기본 원칙
- SOILD 원칙 5가지
- SRP(Single Responsibility Principle) : 단일 책임 원칙
- OCP(Open Closed Priciple) : 개방 폐쇄 원칙
- LSP(Listov Substitution Priciple) : 리스코프 치환 원칙
- ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
- DIP(Dependency Inversion Principle) : 의존 역전 원칙
단일 책임 원칙 - SRP (Single Responsibility Principle)
- '클래스(객체)는 단 하나의 책임만 가져야 한다'는 원칙
→ 책임 = 기능 담당
- 즉, 하나의 클래스는 하나의 기능 담당하여 하나의 책임을 수행하는데 집중되도록 클래스를 따로 따로 여러개 설계하라는 원칙
- 만일 하나의 클래스에 기능(책임)이 여러개 있다면 기능 변경(수정) 이 일어났을 때 수정해야할 코드가 많아짐
Ex) A를 수정하면 B도 수정, B를 수정하면 C도 수정하면서 연쇄적인 수정이 발생
- 단일 책임 원칙의 목적은 프로그램의 유지보수성을 높이기 위한 설계 기법
개방 폐쇄 원칙 - OCP (Open Closed Principle)
- '확장에 열려있어야 하며, 수정에는 닫혀있어야 한다'는 원칙
- 기능 추가 요청 시 클래스를 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화 하도록 프로그램을 작성해야 하는 설계 기법
- [ 확장에 열려있다 ] = 새로운 변경 사항이 발생했을 때 유연하게 코드를 추가함으로써 큰 힘을 들이지 않고 애플리케이션의 기능을 확장할 수 있음
- [ 변경에 닫혀있다 ] - 새로운 변경 사항이 발생했을 때 객체를 직접적으로 수정을 제한
- 추상화 사용을 통한 관계 구축을 권장
- 즉, 다형성과 확장을 가능케 하는 객체지향의 장점을 극대화하는 기본적인 설계 원칙
- 코드의 확장성을 높이고, 기존 코드의 안정성을 유지 가능
리스코프 치환 원칙 - LSP (Liskov Substitution Principle)
- '자식 클래스가 부모 클래스의 기능을 해치지 않으면서 교체 가능해야 한다'는 원칙
→ 다형성을 올바르게 활용하기 위한 개념
- 즉, 다형성의 특징을 이용하기 위해 상위 클래스 타입으로 객체를 선언하여 하위 클래스의 인스턴스를 받으면 업캐스팅된 상태에서 부모의 메서드를 사용해도 동작이 의도대로 흘러가야 하는 것을 의미하는 것
- 기본적으로 LSP 원칙은 부모 메서드의 오버라이딩을 조심스럽게 따져가며 해야 함
→ 자식 클래스가 부모 클래스의 메서드를 재정의(오버라이딩)할 때 부모의 의도를 따르지 않고 다른 동작을 하도록 변경하면 이 원칙이 깨짐
인터페이스 분리 원칙 - ISP (Interface Segregation Principle)
- '인터페이스를 각각 사용에 맞게 끔 잘게 분리해야한다'는 원칙
- SRP 원칙이 클래스의 단일 책임을 강조한다면, ISP 원칙은 인터페이스의 단일 책임을 강조
- 즉, SRP 원칙의 목표는 클래스 분리를 통해 이루어진다면, ISP 원칙은 인터페이스 분리를 통해 설계하는 원칙
- 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써, 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것이 목표
→ 클라이언트는 자신이 필요한 메서드만 포함된 인터페이스 사용
- 단, ISP 원칙의 주의해야 할 점은 한 번 인터페이스를 분리하여 구성해놓고 추후 수정사항이 생겨서 또 인터페이스들을 분리하는 행위를 가하지 말아야 함
→ 인터페이스는 한 번 구성하였으면 왠만해선 변하면 안되는 정책 개념
의존 역전 원칙 - DIP (Dependency Inversion Principle)
- '어떤 Class를 참조해서 사용해야하는 상황이 생길 경우 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스 or 인터페이스)로 참조하라'는 원칙
- 즉, 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 뜻
- 의존 관계를 맺을 때 변화하기 쉬운 것 or 자주 변화하는 것보다 변화하기 어려운 것 or 거의 변화가 없는 것에 의존하라는 것
- DIP 원칙의 목표는 클래스 간의 결합도를 낮추는 것
- DIP를 준수하면 구현 세부 사항이 변경되더라도 상위 요소에 의존하는 코드에서는 최소한의 변경만 발생하게 되므로, 확장성과 유지보수성이 크게 향상
참고자료
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
