SOLID
- 로버트 마틴이 명명한 객체 지향 설계의 5가지 기본 원칙
- 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 코드를 리팩토링하여 냄새를 제거하기 위해 적용할 지침
- 5가지로는 다음과 같다.
- SRP(Single Responsibility Priciple)
- OCP(Open Closed Principle)
- LSP(Liskov Substitution Principle)
- ISP(Inerface Segregation Principle)
- DIP(Dependency Inversion Principle)
SRP
- 단일 책임 원칙
- 한 클래스는 하나의 책임만 가져야 한다. 그리고 클래스는 그 책임을 완전히 캡슐화해야 한다.
- 문맥과 상황에 따라 다르다.
- 로버트 마틴은 책임을 변경하려는 이유로 정의. 클래스나 모듈이 변경하려는 이유를 단 하나만 가져야 한다고 한다.
- 중요한 기준은 변경. 변경을 하였을 때 파급 효과가 적으면 SRP를 잘 따른 것.
OCP
- 개방-폐쇄 원칙
- 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 다형성 활용
- 인터페이스를 구현헌 새로운 클래스를 하나 만들어서 새로운 기능 구현
- 잘 적용이 된 경우 기능 추가 혹은 변경이 필요한 경우 기존 코드를 변경하지 않고 코드를 추가함으로써 기능의 추가 및 변경이 가능하다.
- 구현 객체를 변경할 때에는 클라이언트 코드를 변경해야 한다. -> 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP
- 리스코프 치환 원칙
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 기능적으로 보장으로 해야 한다.
- 몇 가지 표준적인 요구사항을 강제한다.
- 하위 타입에서 메서드 인수의 Contravariant
- 하위 타입에서 반환형의 Convariant
- 하위 타입에서 메서드는 상위 타입 메서드에서 던져진 예외 유형을 제외하고 새로운 유형의 예외를 던지면 안 된다.
ISP
- 인터페이스 분리 원칙
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다는 낫다.
- SRP와 비슷
- 분리 시 클라이언트에 영향을 주지는 않는다.
- 인터페이스가 명확해지고 리팩토링, 수정, 재배포를 쉽게 할 수 있다.
DIP
- 의존관계 역전 원칙
- 구체화에 의존하지 않고 추상화에 의존할 것. (인터페이스에 의존)
- 상위 모듈은 하위 모듈에 의존해서는 안 된다.
- 유연하게 구현체 변경 가능
- 클라이언트가 구현 클래스를 직접 선택하지 않게 한다.
참고
- 강의 - https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard
- https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
- https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99
- https://ko.wikipedia.org/wiki/%EA%B0%9C%EB%B0%A9-%ED%8F%90%EC%87%84_%EC%9B%90%EC%B9%99
- https://ko.wikipedia.org/wiki/%EB%A6%AC%EC%8A%A4%EC%BD%94%ED%94%84_%EC%B9%98%ED%99%98_%EC%9B%90%EC%B9%99
- https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4_%EB%B6%84%EB%A6%AC_%EC%9B%90%EC%B9%99
- https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EA%B4%80%EA%B3%84_%EC%97%AD%EC%A0%84_%EC%9B%90%EC%B9%99
개발자를 원하는 사람.