From 9241c2c30502991444026b77e70884685a1e35f2 Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Thu, 23 May 2024 09:24:14 +0900 Subject: [PATCH] =?UTF-8?q?=EC=83=81=EB=B2=94=209=EC=9E=A5=20(#53)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\203\201\353\262\224.md" | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 "\354\261\225\355\204\260_9/\354\203\201\353\262\224.md" diff --git "a/\354\261\225\355\204\260_9/\354\203\201\353\262\224.md" "b/\354\261\225\355\204\260_9/\354\203\201\353\262\224.md" new file mode 100644 index 0000000..5deaba4 --- /dev/null +++ "b/\354\261\225\355\204\260_9/\354\203\201\353\262\224.md" @@ -0,0 +1,73 @@ +# 9장 - 계층형 설계 2 + +## **계층형 설계 패턴** + +- 패턴1: 직접 구현 +- 패턴2: 추상화 벽 + - 호출 그래프에 어떤 계층은 중요한 세부 구현을 감추고 인터페이스를 제공함 + - 인터페이스를 사용하여 코드를 만들면 높은 차원으로 생각할 수 있음 +- 패턴3: 작은 인터페이스 + - 시스템이 커질수록 비즈니스 개념을 나타내는 중요한 인터페이스는 작고 강력하게 구성하는 것이 좋음 +- 패턴4: 편리한 계층 + - 계층형 설계 패턴과 실천 방법은 개발자의 요구를 만족시키면서 비즈니스 문제를 잘 풀수 있어야 한다. + - 소프트웨어를 더 빠르고 고품질로 제공하는데 도움이 되는 계층에 시간을 투자해야함 + - 그냥 좋아서 계층을 계속 추가하면 안됨. 코드가 속한 추상화 계층은 작업할 때 편리해야함 + + +## **패턴2: 추상화 벽** + +- 책임을 명확하게 나눔 +- 세부 구현을 감춘 함수로 이루어진 계층 +- 사용할 때는 구현을 전혀 몰라도 됨 +- 라이브러나 API 와 비슷하다. 외부 API는 그 API를 사용하는 곳은 신경쓰지 않는다. +- 추항화 계층 내에서 사용하는 데이터의 구조가 바뀌어도 추상화 계층에는 영향이 가지 않아야 한다. + +### **추상화 벽 사용 타이밍** + +- 쉽게 구현을 바꾸기 위해 +- 코드를 읽고 쓰기 쉽게 만들기 위해 +- 팀 간에 조율해야 할 것을 줄이기 위해 +- 주어진 문제에 집중하기 위해 + +## **패턴3: 작은 인터페이스** + +- 작은 인터페이스 패턴은 새로운 코드를 추가할 위치에 관한 것 +- ex) 장바구니에 제품을 많이 담은 사람이 시계를 구입하면 10% 할인해주려고 한다. +- 방법1) 추상화 벽에 만들게 되면 장바구니에 접근할 수 있다. 허나 같은 계층에 있는 함수 사용을 못함 +- 방법2) 해시 데이터 구조를 직접 접근할 수 없음. 추상화 벽에 있는 함수를 사용해야함 +- 결론: 방법2가 낫다. +- 방법1의 문제점 + - 추상화 벽에 만드는 함수는 개발팀과 마케팅팀 사이의 계약임 + - 새로운 함수가 생긴다면 계약이 늘어나는 것과 같음 +- 추상화 벽에 코드가 많을수록 구현이 변경되었을 때 고쳐야 할 것이 많다 +- 추상화 벽에 있는 코드는 낮은 수준의 코드이기 때문에 더 많은 버그가 있을 수 있다 +- 낮은 수준의 코드는 이해하기 더 어렵다 +- 추상화 벽에 코드가 많을수록 팀 간 조율해야 할 것도 많아짐 +- 추상화 벽에 인터페이스가 많으면 알아야 할 것이 많아 사용하기 어려움 + +--- + ++) 회사에서 [장바구니 기능을](https://coloso.co.kr/cart) 만듦, 장바구니 목록 데이터 구조가 배열인데 해시맵으로 바뀌었을 때 이점이 있는지가 궁금하다 +⇒ 탐색/검색 에선 분명히 이점이 있을 것임, 시간복잡도 O(1) +⇒ 장바구니는 최대 50개만 담을 수 있다면, 유의미할까? +⇒ 추가/삭제 도 시간복잡도는 O(1)일 것임. 근데 삭제할때 선택해서 삭제가 가능. + +```jsx +// as-is(데이터 구조 - 배열) delete +const bucket = cartStore.bucket.filter(({ id }) => !cartIds.includes(id)); +setCartStore({ bucket }); + +// to-be(데이터 구조 - 해시맵) delete +cartIds.forEach((cartId) => { + bucket.delete(cartId); +}); +``` + +⇒ 결국, 대용량 데이터 처리가 필요한 경우가 아니라면 오히려 연결리스트에 대한 포인터를 유지하기 떄문에 메모리 사용량이 증가하는 단점만 초래하지 않을까 생각이 듦 + +## **요약** + +- 추상화 벽 패턴을 사용하면 세부적인 것을 완벽히 감출 수 있기 때문에 더 높은 차원에서 생각할 수 있음 +- 작은 인터페이스 패턴을 사용하면 완성된 인터페이스에 가깝게 계층을 만들 수 있음 +- 편리한 계층 패턴을 이용하면 다른 패턴을 요구 사항에 맞게 사용할 수 있음 +- 호출 그래프 구조에서 규칙을 얻을 수 있음 어떤 코드를 테스트하는 것이 가장 좋은지, 유지보수나 재사용하기 좋은 코드는 어디에 있는 코드인지 파악 가능함 \ No newline at end of file