translation/write_solid_react_hooks/

글을 읽다 보니 SOLID를 만든 로버트 C. 마틴의 설명을 조금 벗어난다고 느끼는 부분들이 있었고 단어를 항상 엄밀하게 쓸 필요는 없지만 혹시 다른 분들에게 개념이 잘못 받아들여질까봐 슬쩍 의견 달아봅니다 원본 아티클은 댓글창이 없네요 ^^;;

SOLID는 기본적으로 객체지향 원칙이라 상속 기반으로 설계되지 않는 component / hooks 함수에는 딱 들어맞지 않는 부분이 존재합니다. 원 개념을 제대로 인용하고 있다기보다 비슷한 내용의 설명을 위해 개념을 빌려 쓴 느낌으로 보는 것이 맞지 않을까 싶어요

즉 예제의 코드 개선 자체는 좋은 리팩토링이지만, 이게 SRP다~ 이게 DIP다~ 라고 대놓고 분류하는 것은 오개념이라고 생각합니다

SRP

인용문으로 들어온 단 하나의 액터만 담당해야 한다가 더 핵심이고, 모듈/클래스에 대한 원칙이지 함수가 한 가지 일을 하도록 한다는 다른 원칙입니다만 내용이 비슷하다보니 여기도 갖다 쓰이는 경우가 많습니다 (라고 SOLID의 창시자 분이 설명하십니다. reference: Clean Architecture의 SRP 설명)

OCP

추상화를 활용하는 것이 OCP 설명에 주로 사용되지만, 그래도 요건 그나마 적당해보이네요

LSP

상속/오버라이딩 상황에서 나오는 개념인데 예제는 단순 펑션을 이야기하고 있어서 딱 들어맞진 않습니다만... 언어를 통해 실제로 그렇게 구현하지 않더라도 이 예제는 네이밍을 통해 간접적으로 useLocalAndRemoteStorage가 useLocalStorage의 서브타입이라고 상상하거나 그렇게 설계도를 그려놓는 것을 의도한 것 같아서 어느 정도 납득의 여지는 있네요

ISP

첫 번째 예시는 적절하다고 생각하는데 두 번째로 설명하는 "typescript가 아니어도 ISP 원칙은 관련성이 있다"는 설명은 예제를 상세하게 들여다보면 결국 내부적인 (보이지 않는) 정적 타입 개념이 있다고 가정하는 예시인 것 같아서 적합한지 의문이 들긴 합니다

DIP

의존성 주입이 의존성 역전을 달성하는 유일한 방법은 아니라는 점을 기억하세요 까지는 맞는데, hook의 사용이 의존성 역전 원리를 구현한다는 말은... 매우 잘못된 이야기 같습니다

구현을 소스에서 직접 참조하고 있는지 아닌지가 SOLID와 DIP에서 이야기하는 의존성(제어흐름과 대조되는 개념)의 가장 기본적인 기준이 되고 그 기준 안에서 여러 가지 솔루션들이 나오는 것인데

모듈에서 직접적인 DI(의존성 주입)을 사용하지 않고 DIP를 준수하려면 서비스 로케이터나 팩토리를 통해 해결해야지, 구체적인 구현이 담긴 hook을 직접 사용하는 것은 어떤 방향으로 생각해도 의존성 역전이 진행된 것으로 이야기하긴 좀 어려워 보입니다

방향 자체는 좋은 글이니 위 부분들은 대충 흐린눈으로 넘어가도 된다고 저도 생각합니다 ㅎㅎ 다만 용어를 지은 사람이 있고 명확한 용어의 정의가 있다 보니 조금 정확하게 선을 그어두고 받아들일 필요는 있다고 봅니다

저도 너무 단어의 사용을 빡빡하게 제한하고 있거나 잘못 인지하고 있는 부분들이 있을 수 있으니 다른 의견도 환영합니다!!

ykss / ykss.netlify.com

translation/write_solid_react_hooks/ #120

(번역) SOLID 원칙으로 리액트 훅 작성하기 | Ykss

SRP

OCP

LSP

ISP

DIP