generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Topic 28 * 5장 정리
- Loading branch information
Showing
1 changed file
with
114 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,114 @@ | ||
## 5장 구부러지거나 부러지거나 | ||
이전 내용에서 되돌릴 수 없는 결정이 얼마나 위험한지 이야기 했다. 이번 장에서는 되돌릴 수 있는 의사 결정을 내리는 구체적인 방법을 설명한다. | ||
|
||
- 유연함을 유지하는 한가지 좋은 방법은 코드를 적게 작성하는 것 | ||
- 코드 수정은 새로운 버그가 생기는 계기기도 하니까 | ||
- 세부 사항을 완전히 코드 밖으로 옮기기 | ||
- 선언적 프로그래밍의 핵심 | ||
|
||
이런 모든 기법을 활용하면 코드가 부러지지 않고 구부러진다! | ||
|
||
## Topic 28. 결합도 줄이기 | ||
결합도가 낮은 코드가 바꾸기 쉽다. | ||
|
||
### 열차사고: 연쇄 메서드 호출 | ||
TDA: 묻지 말고 말해라. | ||
> 굳이 알지 않아도 되는 것은 함수 내부에 숨기고 중요한건 매개변수로 넘기는 방식을 표현한 문장이라고 생각했음. <= 선언적 프로그래밍의 핵심이라 생각 | ||
> **어떤 객체의 내부 상태에 따라 판단을 외부에서 내려 그 객체를 수정하는 행위 X** <= 근데 사실 이게 핵심 | ||
TDA는 자연 법칙이 아니라 문제를 알아볼 수 있게 도와주는 패턴. | ||
|
||
#### 데메테르 법칙 | ||
- 메서드 호출을 엮지말라 | ||
|
||
### 글로벌화: 정적인 것의 위험함 | ||
- 전역 데이터는 코드의 결합도를 높인다 | ||
- 전역 데이터는 코드를 떼어내는데 문제를 만든다 | ||
- 전역 데이터를 피하라 | ||
- 싱글턴도 전역 데이터다 | ||
- 수정 가능한 외부 리소스도 전역데이터다 | ||
|
||
### 상속은 결합을 늘린다. | ||
|
||
### 결국은 모두 ETC | ||
- 직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 유지하자 | ||
|
||
|
||
## Topic 29. 실세계를 갖고 저글링하기 | ||
|
||
이벤트 기반 애플리케이션의 4가지 전략 | ||
|
||
### 유한 상태 기계 | ||
- 이벤트를 어떻게 처리할지 정의한 명세 | ||
- 데이터로만 표현 가능 | ||
- 행동도 추가하여 상세 표현 가능 | ||
|
||
> 사용해본 적 없음 | ||
### 감시자(Observer) 패턴 | ||
- 이벤트를 발생시키는 “감시 대상”, 이벤트에 관심이 있는 “감시자” | ||
- 감시자는 자신이 관심 있는 이벤트를 감시 대상에 등록 | ||
- 해당 이벤트가 발생하면 감시 대상은 등록된 감시자 목록을 보면서 함수들을 일일이 호출 | ||
|
||
### 단점 | ||
- 모든 감시자가 감시 대상에 등록 해야 함 → 결합 | ||
- 일반적으로 감시 대상이 직접 콜백을 호출하도록 구현 → 성능 병목 | ||
|
||
> 리액티브 프로그래밍의 근간이 되는 패턴 | ||
## 게시-구독(Pub/Sub) 패턴 | ||
- 감시자 패턴을 일반화 | ||
- 게시자와 구독자가 있고 채널로 연결된다. | ||
- 구독자는 관심사를 하나 이상의 채널에 등록하고, 게시자는 채널에 이벤트를 보낸다. | ||
|
||
### 장점 | ||
- 비동기 이벤트 처리가 가능 | ||
- 채널을 추상화해 결합도를 줄임 | ||
|
||
### 단점 | ||
- 전체적인 이벤트 처리 상황을 바로 파악하기 힘듦 | ||
|
||
> ![image](https://github.com/user-attachments/assets/85b1be9c-b98d-4a90-a8d1-b497d63eee89) | ||
> react-query 코어 내부 동작은 observer 인가 pub/sub 패턴 인가.. 둘 다 섞은 패턴일까? | ||
|
||
## Topic 30. 변환 프로그래밍 | ||
- 프로그램이란 입력을 출력으로 바꾸는 것 | ||
- 파이프라인 연산자는 자동으로 데이터 변환의 관점에서 생각하게 해준다. | ||
- 상태를 쌓아 놓지 말고 전달하자 | ||
|
||
## Topic 31. 상속세 | ||
- 상속은 결합이다 | ||
|
||
### 더 나은 대안 | ||
- 인터페이스 | ||
- 다형성을 필요로 할 때 정답이 되어준다 | ||
- 위임 | ||
- Has-A가 Is-A보다 낫다 | ||
- 믹스인 | ||
- 처음 보는데 유틸함수 같은 느낌. 이것도 거대해지면 나중에 문제 생기지 않나..? | ||
결론: 상속이 답인 경우는 드물다 | ||
|
||
> 상속은 유연한 변경을 어렵게 만든다. | ||
## Topic 32. 설정 | ||
- 외부 설정으로 애플리케이션을 조정할 수 있게 하라 | ||
- 기본적으로 나중에 바뀌리라 알고 있는 것, 소스코드 밖에서 표현할 수 있는 것을 찾아 설정에 던져 놓기 | ||
|
||
### 정적 설정 | ||
- 파일, DB 에서 불러올 수 있는 설정 방법 | ||
- 어디에서든 설정정보를 접근하기 보단, 한겹 추상화 해서 API 뒤로 감춰놓는 것도 좋음 | ||
|
||
### 서비스형 설정 | ||
- 외부 서비스 API로 불러오는 설정 방법 | ||
|
||
#### 장점 | ||
- 여러 앱에서 설정 정보 공유 가능 | ||
- 인증과 접근제어를 붙여 앱마다 보여지는 정보를 다르게 하거나 접근 불가능하도록 할 수 있음 | ||
- 여러 인스턴스에 걸쳐 전체 설정을 한번에 변경 가능 | ||
- 동적으로 계속 바꿀 수 있음 | ||
|
||
> 지금 회사에서 서비스형 설정을 쓰고 있는데 서비스 관리하기 편해보임 | ||
|
||
|