🐘 SOLID 정리 🐘

SOLID

객체지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙

코드 확장, 유지 보수 관리가 쉬워진다.
또, 복잡성을 제거해 리팩토링에 소요되는 시간을 줄임으로써 개발의 생산성을 높인다.

SRP : 단일 책임 원칙

프로그램의 유지보수성을 높이기 위한 설계 기법

• 객체는 단 하나의 책임(=기능)만을 가져야 한다.
• 기능 변경(수정)이 일어났을 때 다른 책임의 변경으로의 연쇄 작용을 극복한다.

컴퓨터 클래스는 컴퓨터의 기능만 구현한다.
컴퓨터가 청소를 하거나 설거지를 할 책임이 없다.
즉, 컴퓨터는 컴퓨터의 기능만 잘 하면 되는 책임만 가지면 된다.

OCP : 개방 폐쇄 원칙

확장에 열려있어야 하며, 수정에는 닫혀있어야 한다는 원칙

• 기능 추가 요청이 오면 클래스 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화해야 한다.
• 확장에 열려있다 = 새로운 변경 사항이 발생할 경우 유연하게 코드를 추가한다.
• 변경에 닫혀있다 = 새로운 변경 사항이 발생할 경우 객체를 직접 수정하는 것을 제한한다.
• 추상화 사용을 통한 관계 구축을 권장한다.

부모 클래스) Animal - 자식 클래스) Dog, Cat이 있을 때 
새로운 클래스 Duck을 추가할 경우 기존 Animal의 코드를 변경하지 않고 Duck 클래스를 구현할 수 있다.

LSP : 리스코프 치환 원칙

다형성 원리를 이용하기 위한 원칙 개념

• 서브 타입은 언제나 기반(부모) 타입으로 교체할 수 있어야 한다.
• 상위 클래스 타입으로 객체를 선언해 하위 클래스의 인스턴스를 받으면, 업 캐스팅된 상태에서 부모의 메서드를 사용해도 동작이 의도대로 흘러가야 한다.

예기치 못한 문제 발생 가능성이 있어 부모 메서드의 오버라이딩을 따져가며 해야한다.

Father 아들 = new Son(); → 불가능, 아들은 아빠가 될 수 없다.
Father 딸 = new Daughter(); → 불가능, 딸은 아빠가 될 수 없다.
Animal 뽀로로 = new Penguin() → 가능, 뽀로로는 펭귄이자 동물이다.

ISP : 인터페이스 분리 원칙

인터페이스의 단일 책임 강조

• 인터페이스를 각각 사용에 맞게 분리해야 한다.
• 클라이언트 기준으로 인터페이스를 분리해 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것이 목표이다.
• 인터페이스를 한번 구성한 뒤 변경하면 안된다.

Object라는 인터페이스를 Car, Bird 클래스가 구현할 때, Car에서는 drive, speed와 같이 자동차와 관련된 기능을, 
Bird에서는 Fly, Step과 같이 새와 관련된 기능을 구현하게 된다. 

이때 Car에 Fly, Step와 같이 새의 기능을 구현해야 하는 경우가 생기며, 
Bird에서도 반대의 경우가 생기게 되면서 클래스 목적에 맞지 않는 메서드로 인해 인터페이스 분리 원칙을 위반한다.

따라서 이를 해결하기 위해 ISP를 적용해 각각 Car와 Bird 인터페이스를 구분하여 구현한다.

DIP : 의존 역전 원칙

상위 인터페이스 타입의 객체로 통신하라는 원칙

• 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다.
• Class를 참조해서 사용해야 하는 상황이 생겼을 때, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스/인터페이스)로 참조하는 것이다.

게임에서 캐릭터가 있을때, 캐릭터는 무기를 가진다.

이때 이 무기는 여러 종류(칼, 총, 방망이 등)를 가진다.
캐릭터는 여러 개의 무기를 가질 수 있으며, 무기 변경이 가능해야 한다.

따라서 모든 무기를 포함하는 인터페이스를 만들고, 이 인터페이스를 무기에 따라 다르게 구현함으로써
무기가 캐릭터에 의존하는 것이 아니라 모든 무기를 포함하는 인터페이스에 의존하게 된다.

이로써 의존성 역전 원칙을 지킬 수 있다.

참고-SOLID
참고-OCP
참고-ISP
참고-DIP