SOLID 원칙이란?

SOLID 원칙의 목적은?

• 변경에 유연하다.
• 이해하기 쉽다.
• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.

 

SRP: 단일 책임 원칙 (Single Responsibility Principle)

모든 클래스 혹은 메소드는 각각 하나의 책임만 가져야 한다..

그러기 위해서는 각 클래스 혹은 메소드는 응집도는 높고, 결합도는 낮아야 한다.

이를 위해서 각 모듈을 변경 해야하는 이유는 오직 하나 뿐 이어야 한다.

만약, 클래스, 메소드를 변경하는 데 다른 여러가지 이유가 있다면 리팩토링 해보자.

 

 

OCP: 개방-폐쇄 원칙 (Open-Closed Principle)

소프트웨어 개체는 확장에는 열려 있어야하고, 변경에는 닫혀 있어야 한다.

기능이 확장될 때, 기존의 코드를 변경하지 않으면서 기능을 확장할 수 있도록 설계해야한다.

예를 들어, 전략 패턴 (Strategy Pattern)을 통해, 소스 코드 의존성은 인터페이스에 의존하여, 런타임시에 전략(실제 구현체)를 변경할 수 있다.

 

LSP: 리스코프 치환 원칙 (Liskov Substitution Priniciple)

자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다.

부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙이며, 이는 객체 지향 프로그래밍에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스터스를 사용해도 문제가 없어야 한다는 것을 의미한다.

 

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)

한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다.

자신이 사용하지 않는 기능(인터페이스)에는 의존하지 않아서, 영향을 받지 말아야 한다는 의미이다.

만약 인터페이스를 구현한 클래스에서 필요 없는 메소드를 오버라이딩 하고 있다면, 인터페이스를 적절히 분리해보자.

 

DIP: 의존성 역전 원칙 (Dependency Inversion Principle)소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않아야 한다.

변동성이 큰 구체적인 요소의 경우 즉 자주 변경될 수 밖에 없는 모듈들은 인터페이스로 분리하고 그 기능이 필요한 다른 클래스에서는 구체 클래스가 아닌 인터페이스를 의존해야 한다.

위의 OCP에서 설명한 전략패턴도 DIP 원칙을 따른 좋은 예시가 될 수 있겠다.