Skip to content

Commit 207443a

Browse files
committed
7-3
1 parent a61ed94 commit 207443a

File tree

1 file changed

+78
-0
lines changed

1 file changed

+78
-0
lines changed

챕터_7/우창완.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -292,3 +292,81 @@ const milkCoffee = new MilkDecorator(coffee);
292292
### 7.14 의사 클래스 데코레이터
293293

294294
`Interface.ensureImplements`까지 하는 것은 투머치.. 타입스크립트를 사용하자
295+
296+
### 7.16 플라이웨이트 패턴
297+
298+
플라이웨이트 패턴은 반복되고 비효율적으로 데이터를 공유하는 코드를 최적화하는 구조적 해결 방법
299+
300+
OOP + Data Oriented Programming 과 비슷한 느낌, 데이터 응집성에 포커스를 맞춘다.
301+
302+
`checkoutMember`, `dueReturnDate` 는 Book 의 속성? -> 아니다.
303+
304+
OOP 의 메모리 과도한 점유를 `상태``데이터`의 결합도를 낮춘 형태. 결국 중요한 것은 응집도
305+
306+
### 7.17 행위 패턴
307+
308+
행위패턴이랑 `객체간의 의사소통`
309+
310+
- 관찰자 패턴
311+
- 중재자 패턴
312+
- 커맨드 패턴
313+
314+
### 7.18 관찰자 패턴
315+
316+
관찰자 패턴은 update를 기반으로 상태를 관리 (Subject, Observer)
317+
318+
주체를 업데이트 할때, 데이터 변경을 감지할 때 `update`를 기반으로 동작한다.
319+
320+
Subject: Observer: 1: N, (N:M이 될수도 있음)
321+
322+
> Subject.action -> Subject.nofity(Observer.update()) 형태로 Observer에게 Subject의 상태 변경을 알린다.
323+
324+
```
325+
Subject: 데이터의 주체
326+
327+
action: notify() 를 호출한다.
328+
addObserver, removeObserver: Observer => void
329+
notify: data => void // Observer.update() 자신을 구독하고 있는 Observer에게 상태변화를 알림.
330+
331+
332+
Observer: Subject의 관찰자.
333+
update: () => T // 상태변화에 따른 특정 액션
334+
```
335+
336+
### 7.18.1 관찰자 패턴과 발행/구독 패턴의 차이점
337+
338+
Pub/sub 패턴과의 차이는 변경 전파 책임
339+
340+
관찰자 패턴의 변경 감지 전파의 책임은 Subject에게 있다.
341+
342+
시그니처를 보았을 때는 Pub/sub 더 유연해보이고, 상태 변화/감지의 책임이 더 잘 나누어진 것으로 보였음
343+
344+
하지만, 대부분의 경우는 Subject -> Observer로 바로 상태변화를 알리는 것이 명료해보이지만, 응집도는 많이 떨어짐
345+
346+
아래 사고를 거쳐서 계층의 필요타당성을 생각해보기
347+
348+
- 두 객체간의 결합도를 낮추는 것이 꼭 필요할 때 (분리가 필요한 계층, 계층적으로 달라야 필요성이 있을 듯)
349+
- 발행/구독 계층이 어떤 문제를 해결해주는가?
350+
351+
예시 중, 사용자와 리뷰의 관계가 결합도를 낮춰야할만큼의 다른 계층인가? -> 아니라고 생각함, 오히려 응집도가 낮아짐(161p)
352+
353+
EventEmitter 도 떠오르는데, 어떤 Event가 emit되면 특정 함수를 호출하는 형태도 pub/sub의 일부와 비슷해보인다.
354+
355+
RxJS 처음 본 인상은 Effect(state) => ui 형태로 사이드이펙트를 잘 제어할 수 있으면, 유지보수하기 좋은 형태를 만들 수 있을 것 같지만,
356+
357+
사이드이펙트 관리에 대한 이해가 부족하면 오히려 독이 있을 것 같다 (debugging, 참조 투명성, descriptive name의 부재 등)
358+
359+
### 7.19 중재자 패턴
360+
361+
중재자 패턴은 하나의 객체가 이벤트 발생 시, 다른 여러 객체들에게 알림을 보낼 수 있는 디자인 패턴 -> 관찰자 패턴가 뭐가 다르지?
362+
363+
### 7.20 커맨드 패턴
364+
365+
명령을 trigger하는 객체와 명령을 execute 하는 객체가 분리되어 있는 패턴
366+
367+
책의 예시는 실질적으로 결합도를 낮추지 못한다. 불필요한 추상화
368+
369+
-> `buyVehicle``buyCar` 로 변경되면 execute('buyCar')도 함께 변경되어야 한다.
370+
371+
결합도 관련해서 재밌게 읽은 글 남깁니다!
372+
https://maxkim-j.github.io/posts/coupling

0 commit comments

Comments
 (0)