13장. 타입스크립트와 객체 지향
13.1 타입스크립트의 객체 지향
- 프론트엔드에서도 프레임워크에 의한 DI(Dependency Injection)이 발생한다
- 객체 지향의 DI 개념과는 조금 다르지만, 특정 컴포넌트를 인터페이스라고 가정 할 때 해당 인터페이스는 특정 props 에만 동작하는 것이 아니라 props 가 주입되는 시점 + props 의 형태에 따라 다른 결과를 출력하므로 DI 의 개념에 가깝다
** [p.366] '레이아웃의 변경 사항이 생기면 그저 묵묵히 받아들일 뿐이다' 프론트 개발자의 푸념이 느껴집니다 ㅎㅎㅎㅎㅎ
** [p.366] 항상 프론트에서 객체 지향을 떠올리면 컴포넌트를 떠올렸는데, 컴포넌트에 SOILD 법칙을 전부 적용할 수 있을까요? 어찌 생각하시나요!?
13.2 우아한형제들의 활용 방식
13.2.1 컴포넌트 영역
- 온전히 레이아웃 영역만 담당
** [p.367] SOLID 의 S 인 Single Responsibility(단일 책임 원칙)을 따른다고 보면 되겠네요
13.2.2 커스텀 훅 영역
- 비지니스 로직을 레이아웃과 연결 담당
13.2.3 모델 영역
13.2.4 API 레이어 영역
종합 의견
- 객체 지향을 클래스에만 한정하지 않고 객체 자체로만 보면 좀 더 넓은 개념으로 프론트에 적용이 가능
13.3 캡슐화는 추상화
- 추상화도 객체 지향의 개념에 부합하기 위해 너무 복잡하게 생각할 필요 없이 객체를 잘 모델링 하는 것 만으로도 부합한다
- 컴포넌트의 상태와 props 가 좋은 관계를 가질 수 있도록 잘 다루는 것은 캡슐화의 목적에 부합한다
- 결국 유기적인 어플리케이션을 구상하게 되면 객체 지향은 지켜지는 것에 가깝다
** [p.374] 추상화의 경우 비슷한 역할을 하는 클래스의 더 상위 개념을 이끌어낸 다음 하위 클래스는 해당 상위 개념을 상속 받아서 만드는 것인데 컴포넌트에도 충분히 적용이 가능해 보이지만 프론트의 특성상 기능과 개념만으로 상속이 발생하는 구조는 아니기 때문에 + 컴포넌트의 상속 관계가 깊어지면 오히려 코드가 복잡해 지는 문제로 저자의 고민처럼 직접적인 적용은 어려워 보입니다
** [p.374] p.366 의 레이아웃 변경을 그대로 수용해야만 하는 프론트의 특성상 비지니스 로직이 하루 아침에 뒤집힐리 없는 백엔드와 달리 SOILD 와 같은 원칙을 그대로 적용하기에도 한계가 있어 보입니다. 다만, 해당 원칙이 가지는 장점은 명확하기에 프론트에서도 패턴들이 진화하여 하나의 원칙 같은 것이 생기지 않을까 싶습니다.
** [p.374] 그런데 생태계가 너무 빨리 바뀌는게 트랜드라서 정말 원론적이 원칙이 아니고서는 쉽게 적용이 될만한 것은 만들기 어려워 보이기도 합니다!
13.4 정리
- 정답은 없고 모든것은 장단이 있으니 잘하자!