[SOLID principle] 객체지향 설계원칙 (feat. 후론트라라)

(출처 : 무한도전MBC 나비효과특집)

 

1. Single Responsibility Principle (단일 책임 원칙) 

- 각 모듈은 하나의 책임만을 담당해야 한다. 각 모듈은 변경되는 이유가 하나여야 한다. 
하나의 함수가 하나의 동작만 하도록 설계하라는 원칙 
(모듈을 설계할때는 빵공장을 세우는 것이아닌 '반죽하는 기계', '빵굽는 오븐'과 같이 각자의 역할을 하는 기계를 만드는 것)

**설계할 때 고려사항이 뭐가 있을까? 하나의 책임맡고있니, 응집도높게, 결합도낮게, 우리 조직은 소통에 있어서 유연한가,   

2. Open-closed Principle (개방-폐쇄 원칙) 

확장하는 것에는 열려있고, 수정에는 닫혀있도록 한다. 
기존코드를 변경하지 않고(closed), 새로운 코드를 추가하는 것(open)으로 기능 추가 할수있도록 설계해라.

-> 프론트에서 적용해 볼수 있는 사항 : CCP 컴파운드 컴포넌트 패턴
하위 컴포넌트를 추가해서 상위 컴포넌트의 기능을 새로 확장, 기능 수정 할 수 있다.  

 

3. Liskov Substitution Principle (리스코프 치환 원칙) 

자식은 언제나 부모로 대체될 수 있어야 한다. 구성요소는 반드시 서로 치환 가능해야 한다는 법칙
자식은 부모의 행동을 보존하고, 부모클래스 자리에 자식클래스 넣어도 계획대로 잘 동작해야 된다.

 

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

사용안할거면 구현도 하지마랏!
자신이 사용하지 않을 인터페이스는 구현하지 말아야 한다.
사용하지 않는 인터페이스때문에 영향 받아서도 안된다.

 

5. Dependency Inversion Principle(의존성 역전 원칙) 

의존관계를 맺을때 자주 변화하는 것말고 변화 거의 없는 불변한 것에 의존하도록 할것 
상세히 구현된 내용보다는 인터페이스나, 추상화된 내용과 의존관계를 맺자

프론트에서 적용해 볼수 있는 사항?
필요한 정보를 내부에서 구체적으로 정의하기보다, 외부에서 추상의 형태로 주입받아서 쓰면 어떨까
즉, 구현체에 의지하지 않고, 추상화된 레이어를 두는 형태

**의존성 역전? 소스코드의 의존성이 제어흐름과는 반대방향으로 역전되는 것 
구현함수가 있다고 가정 할 때!
'사용자1김씨'를 직접 넣지 말고, 사용자 = '사용자1김씨'입니다. 라는 형태로 해서 사용자(=>추상화)를 주입하는 형태로 구현하면?
그러면 '사용자1김씨'말고 '사용자9이씨'를 쓰고싶을 때 사용자 = 사용자9로 외부에서 변경하면 되니까!
그리고 사용자에 대한 규약을 인터페이스 형태로 (타입스크립트 쓰면 됨) 미리 선언해 줄 것

- 생각해볼 것 ? 인터페이스 기반 설계, 제어의 역전 설계 (고차함수안의 콜백함수에게 구현 역할을 위임하는 구조)