💾 [CS] SOLID 원칙.

SOLID 원칙은 객체지향 프로그래밍에서 유지보수성과 확장성이 좋은 소프트웨어 설계를 위해 제안된 5가지 중요한 설계 원칙입니다.

이 원칙들을 따르면 코드가 더 구조화되고, 관리하기 쉬워지며, 유연하게 변화에 대처할 수 있습니다.

SOLID 원칙은 다음과 같은 5가지 원칙의 첫 글자를 딴 약어 입니다.

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

정의
- 클래스는 단 하나의 책임만 가져야 하며, 하나의 기능만 담당해야 합니다.
설명
- 클래스를 변경할 이유가 하나뿐이어야 한다는 의미입니다.
- 즉, 클래스가 한 가지 역할에 집중하고 그 역할과 관련된 책임만을 가져야 합니다.
- 이렇게 클래스가 명확하고 이해하기 쉬워지며, 코드 수정이 필요할 때 영향을 받는 범위가 작아집니다.
예시
- 게시글을 관리하는 클래스가 게시글 저장, 수정, 삭제 등 여러 가지 역할을 맡는 대신, 각 역할을 별도의 클래스로 나누는 방식입니다.

정의
- 클래스는 확장에 대해서는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 합니다.
설명
- 새로운 기능을 추가할 때 기존의 코드는 변경하지 않고도 시스템을 확장할 수 있어야 합니다.
- 이를 위해 상속이나 인터페이스를 활용해 기존 클래스의 기능을 확장하는 방식이 권장됩니다.
예시
- 새로운 기능이 필요할 때 기존 코드를 수정하지 않고, 해당 기능을 상속받거나 인터페이스를 구현하는 방식으로 추가하는 것이 개방-폐쇄 원칙에 맞는 설계입니다.

정의
- 서브타입(하위 클래스)은 언제나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 합니다.
설명
- 하위 클래스는 상위 클래스의 규약을 준수해야 하며, 상위 클래스를 사용하는 코드가 하위 클래스로 대체되더라도 정상적으로 동작해야 합니다.
- 이는 다형성(polymorphism) 개념을 따르는 객체지향 설계의 중요한 원칙입니다.
예시
- 만약 Animal이라는 상위 클래스가 있고, Bird와 Fish라는 하위 클래스가 있다면, Bird와 Fish는 Animal 타입으로 대체되어도 문제가 없어야 합니다.

정의
- 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 합니다.
설명
- 하나의 큰 인터페이스보다 여러 개의 작은 인터페이스로 분리하는 것이 더 바람직합니다.
- 이렇게 하면 클라이언트는 자신이 필요로 하는 기능만 선택적으로 사용할 수 있습니다.
- 큰 인터페이스는 사용하지 않는 메서드까지 구현해야 하므로 유지보수가 어려워질 수 있습니다.
예시
- 다양한 작업을 수행하는 Workable 인터페이스를 여러 개 작은 인터페이스(Runnale, Flyable, Swimmable)로 분리하여 필요한 기능만 구현하도록 하는 것이 인터페이스 분리 원칙에 맞는 설계입니다.

정의
- 고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 둘 다 추상화된 것에 의존해야 합니다.
설명
- 고수준 모듈(비즈니스 로직)은 저수준 모듈(세부 구현)과 직접적으로 연결되지 않고, 추상화된 인터페이스를 통해 서로 상호작용해야 합니다.
- 이를 통해 변화에 유연하게 대처할 수 있으며, 코드가 더 확장 가능해집니다.
- 또한, 코드의 재사용성도 높아집니다.
예시
- 서비스 계층이 저장소 계층에 의존하지 않고, 저장소 계층을 추상화한 인터페이스에 의존하도록 설계하는 방식이 의존성 역전 원칙에 해당합니다.
- 이를 통해 저장소 계층의 구현체를 교체하더라도 서비스 계층에는 영향을 주지 않게 됩니다.

SOLID 원칙은 유연하고 유지보수하기 쉬운 시스템을 만들기 위한 기본 가이드 라인을 제공합니다.
이 원칙들을 따름으로써 소프트웨어는 다음과 같은 이점을 얻습니다.

이 원칙들은 객체지향 설계의 모범 사례를 제시하며, 코드를 더 효율적으로 관리하고 확장하는 데 큰 도움을 줍니다.