13.1 타입스크립트의 객체 지향

• 프론트엔드에서도 프레임워크에 의한 DI(Dependency Injection)이 발생한다

• 객체 지향의 DI 개념과는 조금 다르지만, 특정 컴포넌트를 인터페이스라고 가정 할 때 해당 인터페이스는 특정 props 에만 동작하는 것이 아니라 props 가 주입되는 시점 + props 의 형태에 따라 다른 결과를 출력하므로 DI 의 개념에 가깝다

• [p.366] 이런 부분은 확실히 프론트적 관점에서 저자가 고민을 많이하고 있구나라는 생각이 듭니다

• [p.366] 항상 프론트에서 객체 지향을 떠올리면 컴포넌트를 떠올렸는데, 컴포넌트에 SOILD 법칙을 전부 적용할 수 있을까요? 어찌 생각하시나요!?

• [p.366] '레이아웃의 변경 사항이 생기면 그저 묵묵히 받아들일 뿐이다' 프론트 개발자의 푸념이 느껴집니다 ㅎㅎㅎㅎㅎ

13.2.1 컴포넌트 영역

• 온전히 레이아웃 영역만 담당
• [p.367] SOLID 의 S 인 Single Responsibility(단일 책임 원칙)을 따른다고 보면 되겠네요

13.3 캡슐화는 추상화

• [p.374] 추상화의 경우 비슷한 역할을 하는 클래스의 더 상위 개념을 이끌어낸 다음 하위 클래스는 해당 상위 개념을 상속 받아서 만드는 것인데 컴포넌트에도 충분히 적용이 가능해 보이지만 프론트의 특성상 기능과 개념만으로 상속이 발생하는 구조는 아니기 때문에 + 컴포넌트의 상속 관계가 깊어지면 오히려 코드가 복잡해 지는 문제로 저자의 고민처럼 직접적인 적용은 어려워 보입니다
• [p.374] p.366 의 레이아웃 변경을 그대로 수용해야만 하는 프론트의 특성상 비지니스 로직이 하루 아침에 뒤집힐리 없는 백엔드와 달리 SOILD 와 같은 원칙을 그대로 적용하기에도 한계가 있어 보입니다. 다만, 해당 원칙이 가지는 장점은 명확하기에 프론트에서도 패턴들이 진화하여 하나의 원칙 같은 것이 생기지 않을까 싶습니다.
• [p.374] 그런데 생태계가 너무 빨리 바뀌는게 트랜드라서 정말 원론적이 원칙이 아니고서는 쉽게 적용이 될만한 것은 만들기 어려워 보이기도 합니다!