부제: SOLID 원칙으로 생각해보기
SOLID란?
소프트웨어 설계 5원칙
각각의 원칙의 앞글자를 따왔다.
SRP - 단일 책임 원칙
SRP가 위배된 코드
해당 컴포넌트는 두 가지 기능을 한 컴포넌트에서 수행하고 있으므로 SRP에 위반됐다.
분리한 예시
활성화된 유저를 필터링하는 로직(getOnlyActive)을 분리하고, 그것을 사용하여 useActiveUsers라는 커스텀 훅을 만들었다.
OCP - 개방 폐쇄 원칙
소프트웨어 구성요소는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
쉽게 말하면 기존 코드는 유지하고, 새로운 코드로 확장하는 구조
OCP가 위반된 코드
위 예시는 pathname의 분기점에 따라 home으로 갈 때와 dashboard로 갈 때의 기능이 추가된다.
만약 home과 dashboard 외에도 또다른 url을 추가하고 싶으면 Header 컴포넌트를 직접 변경해야 한다.
OCP를 지킨 코드
이처럼 기존의 Header 컴포넌트는 변경하지 않고 확장에 좀 더 용이하게 했다.
예시
카드 컴포넌트를 예시로 들면 하나의 카드만 사용한다면 기존의 코드로도 충분하다.
하지만 이처럼 다양한 카드 컴포넌트가 필요하다면?
1. props 추가
이 방법은 다양한 요구사항이 추가될 수록 코드가 복잡해질 수 있다
2. CardItem의 책임 분리
기존의 컴포넌트를 수정하지 않고 카드의 구성 요서를 잘게 나누어 이를 조합, 합성
RoundCardItem, SquareCardItem 등 다양한 카드 컴포넌트를 만든다.
LSP - 리스코프 치환 원칙
하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 한다
리스코프 치환 원칙은 올바른 상속을 위해, 자식 객체의 확장이 부모 객체의 방향을 온전히 따르도록 권고하는 원칙이다.
하지만 리액트에선 상속 대신 합성을 권고하기에 LSP를 사용하는 일은 드물 것이다.
ISP
클라이언트가 실제로 사용하는 인터페이스를 만들어야 한다는 의미로 인터페이스를 사용에 맞게끔 각기 분리해야 한다는 설계 원칙
ISP가 적용되지 않은 코드
이런 경우 구현에는 문제가 없지만 확장에는 용이하지 못 하다.
이것은 그로인해 문제가 발생한 코드다.
ISP가 적용된 코드
이제 비디오썸네일과 라이브스트림을 둘 다 보여줄 수 있다.
DIP - 의존 역전 원칙
고수준 모듈이 저수준 모듈의 구현에 의존해서는 안 된다.
이 예시는 우리가 전기를 사용하기 위해선 플로그만 끼우면 된다.
배선을 직접 사용하지 않아도 된다.
즉, 컴포넌트를 사용할 때 컴포넌트의 데이터를 가져와서 렌더링하는 것에만 신경을 쓰면 되지 다른 로직에 대해선 신경쓰지 말자는 것이다.
DIP가 위반된 코드
DIP가 적용된 코드
