SOLID 원칙
객체 지향 설계 프로그래밍의 유지보수성과 확장성에 도움이 되는 전략.
주로 객체 지향 언어에 적용되지만 개발 프로세스의 핵심 철학으로 간주된다면 모든 언어에 적용될 수 있디.
리액트를 사용할 때도 유지보수성과 확장성을 위해 solid원칙을 따라야할 필요성이 있다.
단일 책임 원칙
단일 모듈에는 단일 책임.
하나의 책임을 하나의 컴포넌트로 제한한다.
개방 폐쇄 원칙
"확장은 개방, 수정은 폐쇄"원칙.
props+조건부 실행이나 컴파운트 패턴 등으로 확장성을 열어두어야함.
리스코브 치환 원칙
확장을 통해 파생된 클래스는 그 기초가 되는 클래스의 기능을 다 사용 가능해야 한다.
typscript를 사용할 때 interface확장 시 상속받는 interface는 상속하는 interface의 모든 속성을 사용해야한다.
인터페이스 분리 원칙
사용되지 않는 인터페이스 내부의 속성을 상속받지 않도록 인터페이스를 관심사에 맞게 분리하고,
필요한 것들만 취해서사용해야한다.
사용하지 않는 데이터(props)를 주고 받지 않아야한다.
의존성 역전 원칙
각 모듈은 다른 모듈의 세부사항이 아닌 추상화(대리인)에 의존해야한다.
외부 로직을 사용해야할 때 컴포넌트에 구체적인 외부 로직이 작성되는 것이 아니라,
추상화한 인터페이스를 사용하거나, props으로 callback을 전달받아 사용해야한다.
컴포넌트 구조 설계 패턴
계층을 나누는 '기준'을 제시해주는 대표적인 디자인 패턴
- Presentational and Container Component Pattern
- Hooks이 등장한 이후로 로직 재사용은 Hooks를 통해 할 수 있어 많이 사용되지 않는다.
- 컴포넌트 재사용을 할 때에는 유용하다.
- Atomic Design Pattern
- UI 재사용성이 뛰어나다는 장점을 가진다.
- 디자인 시스템을 구축하기 위한 초기 비용이 많이 들고 로직과 상태를 낮은 단위까지 내려줘야 하기 때문에 props drilling issue가 발생할 수 있다.
- atom, molecule까지는 컨텍스트 없이 주로 UI 적인 네이밍으로, organism부터는 context가 포함된 네이밍이 좋다.
이분법적으로 나누고 맹목적으로 따르기 보다는
장점과 단점을 정확히 알고 좋다고 생각되는 것을 뽑아 쓰는 것이 좋다.
내가 생각했을 때에는 전체적인 구조는 Atomic Design Pattern을 따르면서, 비즈니스 로직을 단독으로 사용해야 할 컴포넌트의 경우에는 Presentational and Container Component Pattern을 적용하는 것이 좋다고 생각한다.
컴포넌트 설계 패턴
컴포넌트를 구현할 때 생각해봐야 할 점
- 다양한 사례에 적용할 수 있는 재사용 가능한 컴포넌트를 어떻게 개발할까?
- 사용하기 쉽고 심플한 API를 제공하는 컴포넌트는 어떻게 만들까?
- UI와 기능 모두에서 확장성 가능한 컴포넌트를 개발하려면 무엇이 필요할까?
방법
- 단일 책임
- 레이아웃 관련 스타일은 사용하는 측에서 적용
- 확장성 있게
props으로 컴포넌트를 확장하게 될 때의 문제점
변경사항이 많아질수록 props의 갯수와, 그에 맞는 로직이 내부에 추가되어 거대하고 복잡한
자이언트 컴포넌트가 된다.
- 해결책 1. 컴파운트 컴포넌트 패턴으로 작은 컴포넌트들을 조합해서 사용한다.
- 해결책 2. 도메인(다루는 데이터의 종류)를 기준으로 컴포넌트를 각각 구현한다.
- 처음엔 같은 ui여도 나중에 가면 달라질 수 있기 때문
제어역전 패턴들
제어 역전은 컴포넌트 사용자(개발자)에게 유연성과 제어권을 주는 것이다.
이를 통해 컴포넌트의 확장성과 재사용성을 높일 수 있다.
1. Compound Component 패턴
한 컴포넌트를 props에 따라 잘게 나누어 조립해 사용하는 것.
props데이터 하나당 하나의 sub컴포넌트와 연결.
자신의 상태를 자신이 관리한다.
2. 제어 Props 패턴
부모의 상태를 변경하는 (setState)로직이 포함된 핸들러를 자식 컴포넌트의 props으로 내려주는 것
Compound Component 패턴과 다른 점은 상태를 외부(상위 컴포넌트)에서 관리한다는 것.
3. Custom Hook 패턴
상태 관련 로직을 외부 파일로 분리하는 것.
하지만 제어역전은 코드량이 많아지고 한 눈에 들어오지 않는다는 단점도 있다.
변경될 여지가 있는 컴포넌트에만 적용하는 것이 좋다.
SOLID는 객체지향언어에만 적용되는 개념인 줄 알았는데, 언어를 떠나 유지보수성과 확장성을 위해 지켜야할 원칙이라는 것을 알게되었다. 앞으로 개발을 할 때 계속 떠올리면서 적용해야겠다고 생각했다.
또한 컴포넌트의 디자인 패턴? 설계 패턴?에 대해 궁금했는데
컴포넌트 파일 구조에 대한 패턴이 있고, 컴포넌트 자체를 설계할 때 사용되는 패턴으로 구분이 된다는 것을 알게되었다.
설계 구조 같은 경우 Presentational and Container Component Pattern과 Atomic Design Pattern의 장점들을 취하여 사용해야할 것 같고, 컴포넌트 확장성을 위한 설계는 Compound Component 패턴을 연습해봐야겠다.
