[디자인 패턴] SOLID 원칙

[!!!!!!!!!!!!출처!!!!!!!!!!!!!]https://www.youtube.com/live/iyeRmq24HVk?si=qvMvRP_-Te9I-Mab

 

 

 

is : 나는 ~이다.  클래스의 상속

has : 가지다 , 인터페이스의 구현

 

SOLID

 

Single Responsibility Principle  |  단일 책임의 원칙

 

클래스는 하나의 책임만을 가진다.

하나의 책임을 완전한 캡슐화

클래스의 기능은 이 책임에 부합

부합한 예시

 

각 역할을 분리하여 활용하는 것이 이에 해당

 

 

Open-Closed Principle  |  개방 폐쇄의 원칙

-확장에 대해 열려 있는데, 요구 사항이 변경될 때 모듈이 하는 일에 대해 변경이 가능하다.

 

-수정에 대해서는 닫혀는데, 코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경 가능

 

부합하지 않는 예시

부합한 예시

Shape만 가져와 정의하면 지속적인 확장이 가능해진다.

 

 

Liskov Substitution principle |  리소코프 치환 원칙

파생 클래스는 기본 클래스를 대체 [부모 클래스의 방향성을 따라감]

OOP 상속 사용하면 하위 클래스를 통해 기능 추가 가능

 

 

 

Train은 전진과 후진만 구현할 수 있는데, 슈퍼 클래스의 함수를 무효화하기 때문에 리스코프치환원칙에 위배된다.

 

 

위 train의 위배되는 원칙을 앞뒤, 양옆 움직임으로 인터페이스로 움직임을 분리하면 서로 다른 동작에 대해 구현이 가능하다.

 

 

 

Interface segregation principle  인터페이스 분리 원칙

 

-클라이언트는 자신이 이용하지 않는 메서드에 의존하지 않음

-큰 단위 인터페이스를 작은 단위로 분리하여 의존성 약화와 유연성 강화

 

 

 

Dependency Inversion Principle  |  의존 역전원칙

설명

-클래스간의 직접적인 의존성이 존재하지 않고, 추상화를 통해 의존성을 줄이는 것을 권장

 

 

예시

서로 참조하는 것을 줄여서 종속을 없애는 것이 바람직하다.

 

 

나쁜 코드 예시

스위치가  Door에 의존하고 있는 관계를 보여줌

 

 

Door과 NPC의 ISwitchable을 구현하여 자신의 고유 동작을 구현함

Switch는 인터페이스만 호출한다면 동작을 수행하므로, 의존성이 사라짐

 

 

 

추상 VS 인터페이스

직접적인 상속을 받아 구현한 "IS" 관계

 

 

만약 NPC가 Robot이면서 Switchable이 가능한 경우 상속을 어떻게 하는가?

C#은 다중 상속이 불가능 하기에 고민해 볼 문제.

 

C++은 다중 상속이 가능하나, 다이아몬드 상속이 발생

 

 

다중 상속을 해결하는 Interface

다중 상속에 대한 해결 방법으로 인터페이스를 사용하는 것이 좋다.

Robot은 Is로 상속을 받고, Switchable은 인터페이스를 통해 has 구현을 사용합니다.

 

 

추상, 인터페이스 차이점

상속은 정의

인터페이스는 구체화

 

 

 

 

요약