[DesignPattern] SOLID Principle

Design Pattern 의 SOLID 원칙

Single Responsibility Principle

about

Single Responsibility Principle (단일 책임 원칙)

: 모든 클래스는 하나의 책임만을 가져야한다.

클래스를 구현 할 때, 한 가지 기능에만 중점을 두고 구현해야한다.

Why? : 만약 어떤 클래스가 다중 기능을 소유한다면, 수정하는데 어려움이 있을 수있다. 

따라서, 특정 기능을 수정할 때 , 관련 클래스외에 건들필요강 없도록 설계해야함

단일 책임 원칙을 따르지 않았을 때, 수정이 어려워지고, 코드의 재사용성이 떨어진다.

코드의 재사용성을 높이기 위해서는, 단일 책임 원칙을 따르며, 다형성 을 이용해야한다.

• 다형성 : 하나의 인터페이스를 구현하는 여러 클래스들이 있을 때, 이들을 하나의 타입으로 묶어서 사용하는 것을 의미한다.
• 예를 들어 int 를 + 하는 기능을 수행하는 함수를 , str , float 들도 사용할 수 있도록 만들 수 있다.

---

Open-Closed Principle

about

Open-Closed Principle(개방-패쇄 원칙)

: 소프트웨어 개체(클래스, 모듈, 함수..etc)는 확장에 열려있어야(용이해야)하며, 수정에 닫혀 있어야한다.

소프트웨어 개체는 확장에 OPEN
소프트웨어 개체는 수정에 CLOSE

Why? : 언제 어떤 기능이 추가될 지 모르기 때문에 확장성은 중요하다.

수정하는데에 폐쇄적이여야 하는 이유는 외부에서 주요한 데이터를 수정할 수 도있기 때문에 이를 보호(캡슐화) 해야한다. 

어떤 인터페이스를 가짐으로서, 확장(컨크리트)에 관련된 코드에서 자유로워진다.

파이썬 같은 경우 캡슐화를 위한 접근제어자가 없다,

따라서 변수명 앞에 _ 를 붙여서 의도를 표현 해야한다.

---

Liskov Substitution Principle

about

Liskov Substitution Principle(리스코브 치환 원칙)

: 부모(상위)타입은 자식(하위)의타입은 교체(치환)가능해야한다.

자동차 라는 상위클래스에 대한 클래스가 있을때, 
자동차의 컨크리트클래스인 승용차 , 리무진, 트럭 등 은 모두 자동차의 자식, 하위클래스이다.
리소코브 치환 원칙은
     자동차에 대한 기능을 수행하는 함수가 있을때,
     이 함수는 승용차, 리무진, 트럭 등의 자식 클래스에도 적용될 수 있어야함 을 뜻한다 .

---

Interface Segregation Principle

about

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

: 큰 인터페이스를 작은인터페이스로 분리해야한다. (인터페이스 == 추상)

인터페이스를 너무 큰 개념으로 잡지마라 !!

Why? : 

인터페이스를 너무 큰 개념으로 생성하게 되면, 사용하지않는 인터페이스 기능까지 구현해야한다.

예를 들면, 수륙양용차량 인터페이스가 있다고 해보자 .
그럼 자동차는 수륙양용차량 인터페이스를 상속받고 구현해야한다. 
하지만, 자동차는 수륙양용차량 인터페이스의 기능중에 보트운전관련 기능을 사용하지 않는다.
반대로, 보트는 수륙양용차량 인터페이스의 기능중에 자동차운전관련 기능을 사용하지 않는다.
이런 경우, 인터페이스를 너무 큰 개념으로 잡았기 때문에, 사용하지않는 기능까지 구현해야한다.

따라서, 이런경우를 방지하기 위해서 아래처럼 인터페이스를 분리해야한다.

자동차 인터페이스 생성, 보트 인터페이스 생성
자동차 인터페이스는 자동차운전관련 기능만, 보트 인터페이스는 보트운전관련 기능만 구현한다.

자동차는 자동차 인터페이스를 상속받고 구현한다.
보트는 보트 인터페이스를 상속받고 구현한다.
수륙양용차량 인터페이스는 자동차 인터페이스와 보트 인터페이스를 상속받고 구현한다.

---

Dependency Inversion Principle

about

Dependency Inversion Principle(의존관계 역전 원칙)

: 상위 모듈은 하위 모듈에 의존하면 안된다. 둘다 추상화에 의존해야한다.

상위 모듈 : 변하지 않는 부분    이되어야하고,
하위 모듈 : 변하는 부분        이되어야한다. 

Why? : 
상위 모듈은 하위 모듈에 의존하게 되면,
하위 모듈이 변경될때마다 상위 모듈도 변경되어야한다.

    따라서, 상위 모듈은 하위 모듈에 의존하면 안된다. 

그럼 어떻게 관리를 해야할까 ? 
    상위 모듈과 하위 모듈 사이에 추상화 계층을 두어서,
    상위 모듈은 추상화 계층에 의존하고, 하위 모듈은 추상화 계층에 의존하도록 해야한다.

예를 들어,
    동물원 클래스(상위)가 있다고 해보자.

    동물들은 각각의 클래스로 구현되어있다.
    동물원 클래스는 동물들의 클래스에 의존하고 있다.

    동물의 컨크리트가 늘어나면 동물원 클래스도 수정해야한다.

    이런 경우를 방지하기 위해서,
    동물원 클래스는 동물의 컨크리트를 추상화 시켜서 의존하도록 해야한다.

    동물원 클래스는 동물들의 추상클래스에 의존하고 있다.
    컨크리트동물들은 동물들의 추상클래스를 상속받고 구현한다.

    이렇게 되면, 동물들이 늘어나도 동물원 클래스는 수정할 필요가 없다.

---