#추상화

레이어드 아키텍처의 추상화에 대한 질문입니다

뉴비 개발자, 레이어드 아키텍처의 추상화에 대해 약간의 질문이 있습니다. Repository 클래스와 application layer 클래스들의 추상화를 왜 하는가에 대해 가르침을 받고 싶습니다. 우리가 현재 추상화하는 이유가 기존 기능으로부터 추가적인 고객의 요구를 수정에 닫혀있는 채로 관리하기 위함이라면, infrastructure layer의 repository 클래스들과 application layer의 추상화는 해당 이유에 적합한 이유인가? 에 대한 의문을 갖게 되었습니다. 의존성 역전 법칙을 말그대로 따라간다면 추상화를 하는 것이 맞지만, 의존성 역전 법칙 자체가 의존성 관계를 뒤집어 수정의 가능성을 역전한다의 의미인데 인터페이스와 구현체 비율의 가능성이 1:1일 확률이 매우 높은 상황에서 수정의 가능성을 뒤집는다는 것 자체가 약간 이론에 놀아나는 느낌? 이게 진짜 역전되있는 것이 맞는가? 하는 그런 생각이 들었습니다. 그래서 repository 클래스들를 추상화 할거면 application layer도 추상화 하는 것이 이론상 맞고, application layer를 추상화하지 않을거면 repository 클래스도 추상화하지 않는 것이 내가 이해한대로면 맞다. 로 결정하게 되었습니다. 추상화가 테스트때문이라면 요즘 모킹 라이브러리 잘되어있는데, 라이브러리에 대한 의존성을 제거하기 위해 그런가? 라는 생각도 조금 들었습니다. 제가 나아가고 있는 논리의 방향이 맞는지가 의심스럽고 조심스럽습니다. 선배 동기분들의 가르침을 받고 싶습니다. 읽어주셔서 감사합니다.

리액트 쿼리 로직을 커스텀 훅으로 만들 때, 어디까지 추상화를 하시나요?

안녕하세요. 현재 프로젝트에서 기존 데이터 페칭 로직들을 전부 리액트 쿼리로 옮기면서, 고민이 생겨 질문을 드립니다. 클라이언트 상태와 서버 상태로 폴더를 나누고, 쿼리 로직들을 커스텀 훅으로 만들고 있습니다. 그런데 이 커스텀 훅의 추상화를 어디까지 해야할지 고민이 됩니다. 3개의 서비스 페이지가 있고, 사용하는 쿼리 내부의 로직이 비슷할 경우, 아래의 두 가지 방법을 생각해 봤습니다: 1. 재사용을 위해 매개변수로 URL, URL parameter, Query key를 추가 2. 유지보수를 위해 URL parameter만 매개변수로 추가하고, 개별 커스텀 훅 생성 예시 코드로, 1번의 코드는 `useDashboard('/data', startDate, endDate, 'service01/dashboard');` 이런식으로 사용을 하고, 2번의 코드는 `useService01Dashboard(startDate, endDate);, useService02Dashboard(startDate, endDate);...` 이렇게 사용을 합니다. 현재는 2번의 방식으로 구현을 하고 있습니다. 그 이유로는 불러오는 서버 데이터가 대부분 동일하지만 다른 경우도 있어서 타입을 다르게 줘야했고, URL을 쉽게 구분하기가 어려워서 한 곳에서 관리하고 싶었습니다(URL이 REST API 설계와 다소 거리가 있습니다.). 결론은, 함수 호출자의 입장(데이터를 불러오는 함수)에서 어디까지 알아야하나?가 고민입니다. 리액트 쿼리 깃허브에서 예시도 보고, 이렇게 글을 쓰다보니 현재로썬 2번이 더 맞다고 생각이 들긴 합니다. 여러분은 보통 어떤식으로 구현을 하시는지 궁금해서 이렇게 질문을 드리게 되었습니다. 어떤 의견이라도 좋으니 답변을 주시면 정말 감사할 것 같습니다!

코딩 구조화, 추상화, 알고리즘의 차이점이 뭘까요?

차이점을 정확히 알고싶어요ㅜㅜ

순수객체로 추상화 되었다는 말의 의미?

블로그 글을 읽다가 이해가 안가는 부분이 있어서 찾아왔습니다.. "순수객체로 추상화" 되었다라는 말이 어떤 말인가요? 순수 객체가 무엇인지는 알겠는데, 저 말을 보니 제가 제대로 이해하고 있지 못한 것 같아 질문 올려 봅니다. 블로그 글: https://junilhwang.github.io/TIL/Javascript/Design/Vanilla-JS-Virtual-DOM/#_3-%E1%84%80%E1%85%A1%E1%84%89%E1%85%A1%E1%86%BC%E1%84%83%E1%85%A9%E1%86%B7-virtualdom