면접 결과 정리
좋았던 점
- 당당한 시선처리 + 차분한 말투
- 모르는 점은 모른다고 인정
- 답변에 자신만의 생각이 들어가있는 점, 철학이 담겨져 있는게 느껴졌다
- 설명에 손 제스쳐를 잘 활용한다.
- 면접관과 단순한 질문과 대답이 아닌, 서로 대화를 한다는 느낌이 들었다.
- 대답을 논리적으로 일목요연하게 하려는게 느껴졌다.
아쉬운 점
- 손 제스쳐가 과하다, 가끔은 부자연스럽다고 느껴졌다
- 면접 후반부로 가면서 답변이 루즈해지는 경향이 있다, 두괄식으로 간결하고 명료하게 대답하면 더 좋을 것 같다
- “~인 것 같다.”라는 표현이 많았는데, 확신 있는 표현을 사용하면 더욱 자신감 있어 보일 것 같다
- 질문이 들어오면 바로 답변을 하는 경향이 있는데, 잠깐 텀을 두어도 좋을 것 같다.
- 모르는 질문 내용에 대한 대답을 미리 몇 개 준비해서 활용하면 좋을 것 같다.
면접 후 생각 정리
테스트 코드 우선 작성
## [TDD] 테스트 코드 우선 작성 - 5
### 내용
- 구현 기능 목록을 먼저 작성하는 연습
- 테스트 시작전 최대한의 설계 진행
- 테스트 작성이 쉬운 설계 고민
- 구현 기능 목록을 지속적으로 업데이트하면서 테스트 진행
### 링크
- https://gmlwjd9405.github.io/2018/07/06/strategy-pattern.html
구현에 집중하다보면 설계 때 정했던 우선순위가 헝클어지기 마련이다. 그래서 구현 기능 목록을 먼저 작성한다. 내가 구현 기능 목록을 먼저 작성하는건, 삼천포로 빠지지 않기 위함이다.
TDD는 개발 방법론이지 설계론이 아니다. 어떤 방식으로 구조를 나눌 것인지, 어떻게 합칠 것인지를 최대한 고민해서 탄탄한 설계를 마친 후에 TDD를 시작해 나가야 한다.
TDD와 설계에 익숙하지 않다면, 객체를 테스트할 방법이 도저히 떠오르지 않는 경우가 있다. 객체의 복잡도가 너무 높아서 그렇다.
예를 들자면 난수를 생성자 내부에서 생성하는 LottoNumber 객체다. 어떤 값이 나올지 몰라 테스트가 사실상 불가능하다.
이런 경우 난수를 생성자 외부에서 주입 받게 구조를 변경해야한다.
어쩐지 TDD가 설계를 도와주는 것 같지 않은가? 이런 점 때문에 TDD를 설계론으로 착각하게 되는 것 같다. 그렇지만 이건 모두 구현과정에서 일어난 일이다. 설계과정이 아니다. 프로그래밍으로 비유하자면 컴파일 타임과 런타임의 차이다. 명심하자. TDD는 런타임이다. 설계론이 컴파일 타임이다.
원시값 포장
## [OOP] 원시값 포장 - 3
### 내용
- `LottoNumber`, `Money`, `Rank` 등의 원시 값을 포장
- `getter/setter` 사용을 지양함으로서, '객체에 메세지를 보내라'를 지키려함
- 포장한 객체의 검증로직을 통해 원시값을 신뢰하고 서비스 로직을 구현 해나갈 수 있음
### 링크
- https://manualz.kr/entry/JAVA-원시값-포장에-대해서-알아보록-하겠습니다
원시값을 포장했을 때 장점은 명확하다. 비즈니스 로직에 맞게 해당 값을 검증함으로서 신뢰하고 사용 할 수 있고, 해당 값이 단순한 preemptive 타입의 값인지, 비즈니스 적으로 의미가 있는 값인지 고민 할 필요를 줄여준다. 비즈니스 도메인을 신뢰하고 사용 할 수 있다는 건, 개발자의 퇴근 시간을 앞당겨 주는거나 다름 없다.
토끼책을 1회독 하고 난 후 추가적인 장점이 보인다. 원시값을 포장한 객체를 의인화 할 수 있다. 원시 값에게 메세지를 보낼 수 있다. 원시 값에게 메세지를 보낼 수 있게 되면, 명령을 더 추상화 할 수 있다. 명령을 추상화 하게 되면, 메세지를 주고 받는 객체간 결합도가 낮아진다. 조금 더 객체지향스럽게 사용 할 수 있게 된다.
일급 컬렉션
## [OOP] 일급 컬렉션 - 4
### 내용
- `List<LottoNumber>` 를 `LottoNumbers`로 대체
- `List<LottoTicket>`을 `LottoTickets`로 대체
### 링크
- https://jojoldu.tistory.com/412
사실 일급컬렉션의 장점에 대해서도, 토끼책을 1회독 하고 난 후에야 체감되기 시작했다. 그 전엔 그냥 좋다니까 사용했지…
일급 컬렉션을 사용하지 않으면 기본적으로 JDK 컬렉션이 제공하는 메서드에 의존 할 수 밖에 없다. 컬렉션이 제공하는 메서드만으로 해결이 어려우면, 결국 컬렉션 원소를 꺼내서 직접 접근하는 방법 밖에 없다. 기껏 의인화 시켜놓았는데, 컬렉션 때문에 수동적으로 사용하는 단계를 거쳐야 한다. 아주 마음에 안든다. 그래서 일급 컬렉션 개념이 등장한거 같다.
컬렉션을 객체화 시키고 나니, 컬렉션에게도 메세지를 보낼 수 있다. 컬렉션도 의인화가 되었다.
Enum
## [JDK] Enum - 5
### 내용
- 맞춘 로또 번호별 등수와 상금을 정리하기 위한 `Rank` enum 클래스 생성
- `Rank` 상수 하나당 일치하는 번호 개수, 보너스 번호 일치 여부, 상금, 메세지 출력 양식을 저장시킴
### 링크
- https://inor.tistory.com/12
자바의 Enum 은 단순히 상수 값을 열거하는 것 뿐만 아니라, 나열된 원소 하나하나가 객체라는게 가장 큰 특징이자 장점인거 같다.
Enum을 효과적으로 사용 할 수 있는 경우는 구체적으로 어떤게 있을까? 나는 개인적으로 ‘구조적 불변의 진리를 표현할 때’ 가장 적합한 녀석이라고 생각한다.
구조(모델)의 수가 정해져 있고, 관련되어 처리할 수 있는 특징이 여러개 존재할 때.
트럼프 카드를 예시로 들자면 52장의 카드, 심볼과 숫자라는 특징을 가진다.
이런 녀석들이 가장 적합하다고 생각한다.
생각나는 장점으론
Enum 키워드 자체만으로도 객체들을 열거하고 있다는 의도를 드러낼 수 있다는 것,
추가 인스턴스 생성이나 상속을 방지해준다는 점 정도…
Stream API
## [JDK] Stream API - 3
- `Rank` enum 클래스에서 Stream API의 filter를 적극 활용하여 `Rank` 상수 감별
- 추가적인 Stream API 함수 학습 후 `LottoTickets`의 `joinLottoTickets` 메서드를 작성함
### 링크
- https://github.com/woowacourse/java-lotto/pull/275/commits/723fe500538cc8339b60cae1193513472ac089b3
- https://codechacha.com/ko/java8-stream-concat/
# [JDK] Stream - 1
## 내용
- stream API로 나열중인 데이터들을 곧바로 조합해주는 `.collect(joining())` 메서드에 대해 학습 후 적용함
## 링크
- https://codechacha.com/ko/java8-stream-collect/
StreamAPI의 핵심은 ‘관심사의 분리’라고 생각한다. 컬렉션을 for, while 등 키워드로 루프 돌리면서
어떻게 원하는 데이터를 얻어내고(조작하고), 어떻게 어떤 결과를 만들지 WHAT과 HOW를 고민하는게 아니라,
StreamAPI의 내부에서 알아서 해주겠거니 믿고 어떤 결과를 만들지 WHAT만 고민하게 된다는 점이 StreamAPI의 핵심이다.
가독성이 증가한다는 장점이 가장 먼저 떠오르는데, 코드가 짧아지거나 보기 좋아진다기보단 StreamAPI를 활용한다는 것 자체에서 “여기선 컬렉션에 무언가 하겠구나” 식으로 바로 추측하면서 코드를 읽어 나갈 수 있다.
또한 원본 컬렉션 데이터를 읽기만 하기 때문에 원본 컬렉션 데이터가 변질될 위험이 거의 없다. 원본 데이터는 형태를 유지하면서 내가 원하는 결과만 추가적으로 얻어낼 수 있다.
캐싱
## [OOP] 캐싱 - 4
### 내용
- 중복되어 사용되는 1~45의 `LottoNumber` 인스턴스를 캐싱하는 방법에 대해 공부
- `LottoNumber` 클래스에 `static` 키워드를 통해 인스턴스 캐싱을 진행함
- `LottoNumber` 인스턴스를 생성하여 사용하는 로직들을 캐싱된 인스턴스를 사용하도록 수정함
### 링크
- https://woowacourse.github.io/javable/post/2020-06-24-caching-instance/
# [OOP] 캐싱 - 2
## 내용
- 중복되어 사용되는 52장의 `Card` 객체를 캐싱함
- 최초에는 `CardGenerator` 객체를 생성해서 캐싱했으나, 인비와의 대화를 통해 `Card` 클래스에 직접 캐싱하는 것이 더 자연스럽다고 판단하여 `Card` 클래스 내부에 `static` 키워드를 통해 인스턴스 캐싱을 진행함
## 링크
- https://github.com/Hyeon9mak/java-blackjack/commit/110209b6ba847aefb19e8c8cf73c5d5db4647d5d
캐싱은 불변객체와 늘 함께 다닌다. 불변객체를 지향하다보면 객체 생성이 반복되고, 객체 생성이 소모되는 자원과 생성 회수가 많아지면 자연스럽게 캐싱을 고민하게 된다.
모든 불변객체들을 캐싱 할 건 아니다. 자주 사용되지 않을 객체라면, 필요 할 때만 생성해서 사용하고 GC에게 넘겨서 소멸시키는 것이 더 나을 수도 있다.
자주 사용되는, 캐싱을 할 만한 객체는 구체적으로 떠올려보면 Enum에서 이야기 했던 ‘구조적 불변의 진리’가 다시 등장한다. 로또 번호, 카드 객체 등 구조적으로 변하지 않지만 비즈니스적으로 자주 사용되는 것들. 혹은 일정한 유효범위를 가진 VO 객체들이 주 캐싱 대상이 된다.
캐싱을 구현을 학습하는 과정에서, 최초엔 별도의 캐싱 객체를 만들었다. 그러나 인비와의 대화에서 캐싱 대상이 되는 객체가 static하게 자기 자신을 캐싱하는게 더 깔끔하고 객체지향스럽다는 생각이 들었다. 깔끔하다는 건 내가 캐싱한 객체를 처음 사용하는 개발자가 객체 그 자체에 접근하지, 객체를 캐싱하는 객체에 접근하지 않으니까. 객체지향스럽다는 건 자기 자신을 알아서 관리하는 주도적인 객체의 모습이 그려져서다.
점진적 리팩토링
## [TDD] 점진적 리팩토링 - 2
### 내용
- '로또 피드백' 페이지에 제시되어 있는 점진적 리팩토링을 시도해보았으나, 익숙하지 않아 많은 어려움을 겪음
- '우선 돌아가는 프로그램 상태를 유지하고, 조금씩 수정을 진행하라' 는 메세지만 이해한 것 같음
### 링크
- https://techcourse.woowahan.com/s/zmAj9jfu/ls/npw8YN4M
# [TDD] 점진적 리팩토링 - 3
## 내용
- '우선 돌아가는 프로그램 상태를 유지하고, 조금씩 수정을 진행하라' 는 메세지를 지킴
- 컴파일 에러를 최대한 회피하면서 점진적 리팩토링을 진행함
## 링크
- https://techcourse.woowahan.com/s/zmAj9jfu/ls/npw8YN4M
점진적 리팩토링의 가장 큰 장점은 돌발상황을 대처할 수 있다는 것 같다. 우아한테크코스 과정에선 이 장점을 체감하긴 어렵다. 리팩토링 중 급하게 연락을 받고 나갔다가, 다음 날이 되어서야 다시 리팩토링을 이어나갈 때 비로소 장점을 느끼게 된다.
현업에서는 리팩토링 도중에 급하게 라이브 서버로 현재 코드를 반영해야하는 경우가 있지 않을까?
‘돌아가는 코드’ 상태를 유지하면서 변경된 사항을 라이브 서버에 바로 반영 할 수 있다는건, 개발자의 야근을 막아주는 부적과 다름 없어 보인다.
인터페이스와 추상 클래스
# [OOP] 인터페이스와 추상 클래스 - 5
## 내용
- 유한상태머신 패턴에서 인터페이스와 추상 클래스가 혼용되는 이유에 의문을 가짐
- 제이슨과의 대화를 통해 추상 클래스가 혼용되는 이유에 대한 이해를 가짐
## 링크
- https://hyeon9mak.github.io/why-do-you-use-abstract-class
인터페이스는 객체간 협력을 유연하게 만들어주는 규격이자 약속, 추상 클래스는 객체들의 공통점을 묶어서 추상화 시킨 암묵적인 분류 라고 생각한다.
인터페이스를 사용함으로서 객체간 협력에서 객체간 결합도를 낮추고 대체 가능성을 높여주고, 추상 클래스를 통해 객체들이 공통으로 행하는 행위를 중복되게 구현하는 문제를 해소해준다.
상태패턴을 구현하는 과정에서 인터페이스와 추상 클래스가 혼용된 이유는? 아래 정리해두었다.
https://hyeon9mak.github.io/why-do-you-use-abstract-class/
메세지의 방향, 캡슐화
# [OOP] 메세지의 방향, 캡슐화 - 5
## 내용
- 블랙잭 게임 상태별 배팅 반환 금액을 계산하기 위한 분기문을 줄이기 위해 유한상태머신 패턴을 적용함
- 유한상태머신을 구현하는 과정에서 객체의 책임과 위치에 대한 기준을 찾지 못함
- 미립으로부터 "캡슐화", "메세지의 방향" 키워드를 제공 받음
- 캡슐화와 메세지 방향 키워드를 통해 객체의 책임과 위치에 대한 기준을 선정하고 구현을 진행함
## 링크
- https://hyeon9mak.github.io/우아한테크코스-블랙잭-미션-회고/
메세지가 단방향으로 흐르는게 중요하다는 이야기가 나오는 건, 객체지향에 있어 순환참조가 위험하다는 이야기가 되겠지.
순환참조의 문제점은 무엇일까? 가장 쉽게 떠올릴 수 있는 문제점은 객체의 상태를 예측하기 어렵다는 점이다. 객체간 메세지의 경계가 흐려지고 연쇄적으로 상태 변화가 일어날 수 있다. 객체끼리의 결합도가 높아진다고도 볼 수 있을 것 같다.
순환참조를 끊어내려면(메세지를 단방향으로 흐르게 하려면) 어떻게 해야할까?
가장 쉽게 떠올릴 수 있는 방법은 객체 사이에 인터페이스를 추가하는 것이다.
객체A와 객체B 사이에 객체A <-> 객체B 순환참조가 발생했을 때 인터페이스를 추가하면,
객체A -> 객체C -> 객체B, 객체A -> 객체C <- 객체B 등과 같이 메세지의 방향을 바꿔서 순환을 끊어낼 수 있다.
은유와 객체
# [OOP] 은유와 객체 - 5
## 내용
- 객체지향의 사실과 오해 책을 통해 "객체지향은 현실세계의 모방이다" 라는 도시전설에 대해 재해석하는 시간을 가짐
- 객체는 현실세계의 모방이 아니다. 현실세계를 재창조하는 것이다.
- 객체는 하나의 생명체가 되어야한다. 즉, 객체는 능동적이어야한다.
- `RacingCar`라는 객체는 현실세계의 자동차가 아니다. 자동차와 비슷한 협력과 책임을 가진 객체 덩어리다. 우리는 `RacingCar` 라는 이름을 통해 "앞으로 전진하거나 달리겠군." 이라고 객체의 행동을 유추할 수 있다.
- 객체의 상태를 먼저 결정하고 행동을 결정하면 상태의 내부가 공용 인터페이스에 노출될 가능성이 높아지고(캡슐화 저해), 객체를 고립되게 만들며, 객체의 재사용성이 저하되게 된다. 객체의 행동(협력)부터 결정하고 그에 따른 적절한 상태를 선택하자.
- 이와 관련해서 TDD가 도움을 줄 수 있다. TDD에선 우선 객체가 수행할 행동(메서드)부터 작성해나가기 시작하므로, 자연스럽게 객체의 행동을 중점으로 적합성을 결정할 수 있다.
- 결국 객체지향과 현실세계는 서로 아무런 연관이 없지만, 모두가 알고 있는 일반적인 현실세계 형태로 객체의 이름을 표현하여 객체의 책임과 역할을 유추하기 쉽도록 하는 것이다.
## 링크
- http://www.yes24.com/Product/Goods/18249021
은유와 객체는 사실 적어놓은 내용이 전부라… 따로 정리할 말이 없는거 같다.
커맨드 패턴
# [OOP] 커맨드 패턴 - 5
## 내용
- 커맨드패턴에 대한 학습 진행 후 체스게임의 명령어 `start`, `move`, `status`, `end`에 커맨드 패턴을 적용함
## 링크
- https://gmlwjd9405.github.io/2018/07/07/command-pattern.html
- https://github.com/Hyeon9mak/java-chess/commit/afb789dfe72eeb829e3ba5b411a5242dde4bc725
커맨드 패턴은 GoF의 디자인 패턴 중 하나로, 커맨드들을 캡슐화하고 인터페이스로 연결해서 커맨드의 변경 및 추가에도
기존 커맨드를 호출하는 객체가 별도의 수정 없이 그대로 사용할 수 있게 해준다. 모든 커맨드의 기능을 execute 메서드 구현을 통해
동작 시킨다.
장점은 위에서 말한대로 커맨드를 호출하는 측과 수행하는 측의 결합(의존도)이 떨어진다는 것.
단점은 커맨드 하나당 커맨드 객체 하나가 구현된다는 점? 적은 수의 커맨드를 대상으로 적용할 시, 오버 엔지니어링처럼 보인다는게 단점 일 수 있겠다. 객체지향 관점에선 단점이 없는거나 마찬가지일지도.
flatMap
# [JDK] flatMap - 3
## 내용
- 페어 에드로부터 Stream API의 flatMap 메서드에 대해 배운 후 체스미션에 전반적으로 적용함
## 링크
- https://github.com/Hyeon9mak/java-chess/commit/971c7eb1607b18a53ddf9a5827b651d5e6fa045a
flatMap은 배열이나 Object(HashMap 등) 형태로 감싸져있는 원소들을 단일 원소 스트림으로 변환시켜준다.
체스 미션을 진행하는 동안 <Position, Piece> 형태의 HashMap에서 Piece 원소 스트림으로 원하는 체스 피스를 찾아내는데
사용했다.
사실 상세한 동작원리를 이해했다기보다, 단순히 사용법을 익히고 사용한게 전부라 크게 정리할 내용이 없는거같다… 😅
이벤트 소싱
# [OOP] 이벤트 소싱 - 5
## 내용
- 이벤트 소싱 기법에 대해 학습한 후, 체스게임 명령을 기록하는 방식으로 데이터베이스를 구현함
## 링크
- https://mjspring.medium.com/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%86%8C%EC%8B%B1-event-sourcing-%EA%B0%9C%EB%85%90-50029f50f78c
- https://github.com/woowacourse/java-chess/pull/240/files/5308f2fbc2149f2ccaf6db8a846b2f5e8669a02f#diff-bdbc4966c729e860f82b005ab3903fd146b59de79b1c7c168f8374b3381ada6e
인비가 조이한테 아이디어를 제안하고, 조이가 그것을 ‘이벤트 소싱’ 이라고 부른다는 걸 정리해서 알려주었다.
데이터베이스에 세부 도메인 정보를 기록하는게 아니라, 소프트웨어의 동작 히스토리를 처음부터 끝까지 기록하는 형태다. 대표적으로 바둑이나 장기 등의 게임에서 수를 되돌리거나 복기를 진행할 때 유용하게 사용될 수 있다.
그러나 모든게 그렇듯이 단점 또한 여럿 존재하는데, 대표적으로 히스토리가 깊어(길어)질수록 매 로딩마다 부하가 크게 걸린다는 점이 손꼽힌다. 그 외에 체스미션 중 리뷰어셨던 닉이 “마이그레이션이 어려울 것이다”, “특정 시점에서 보드 관련 쿼리를 날리기 어렵다” 는 추가 단점을 알려주셨다. 마이그레이션은 서버 혹은 데이터베이스 이전 작업을 수행할 때 각 서버(데이터베이스) 프로그램마다 해석하는 명령이 다를 경우 변환이 어렵다는 말이고, 특정 시점에 보드 관련 쿼리를 날리기 어렵다는건 데이터베이스에 명령어만 String형태로 기록되고 있기 때문에 당연한 이야기였다.
Custom Exception
# [Java] Custom Exception - 2
## 내용
- `printStackTrace()` 사용에 대한 피드백을 받은 후 Custom Exception을 적용함
## 링크
- https://github.com/woowacourse/java-chess/pull/240#discussion_r606782916
- https://hyeon9mak.github.io/%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC%EC%BD%94%EC%8A%A4-%EC%B2%B4%EC%8A%A4-%EB%AF%B8%EC%85%98-%ED%9A%8C%EA%B3%A0/#%EF%B8%8F-custom-exception
개인적으로 Custom Exception을 지양한다.
“최대한 있는 걸(Legacy Exception) 사용하고, 도저히 찾아봐도 없으면 그 때 (Custom Exception을) 만들자.”
라는 생각 때문인데, 체스 미션에서 데이터베이스 관련 에러에 대해서 printStackTrace() 만 출력하는 것에 대해 적당한 예외를 다시
던져주는 것으로 피드백을 받았다.
Runtime Exception들을 찾아보았지만, 적당한 녀석을 찾지 못했다. 그러던 중 Spring에서는 데이터베이스 관련 에러를 처리하는 SQLException들을 DataAccessException를 통해 별도 관리한다는 것을 발견하고 간단하게 Custom DataAccessException을 구현했다.
try-with-resources
# [Java] try-with-resources - 4
## 내용
- 데이터베이스 연결 자원 자동 회수를 위한 try-with-resources 구분 사용법과 자원이 자동으로 회수되는 원리 (AutoCloseable 구현)를 학습하고 적용함
## 링크
- https://hyeon9mak.github.io/%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC%EC%BD%94%EC%8A%A4-%EC%B2%B4%EC%8A%A4-%EB%AF%B8%EC%85%98-%ED%9A%8C%EA%B3%A0/#%EF%B8%8F-try-with-resources
블로그에 정리해놓은 글 이 전부.
Service layer, Dto
# [OOP] Service layer, Dto - 5
## 내용
- `BlackjackManager` 객체를 서비스 레이어로 생각해보면서 Dto개념을 도입함
## 링크
- https://umbum.dev/1066
- https://github.com/Hyeon9mak/java-blackjack/commit/db5bd0c1847b67755e02823bc8d98aae577e86a4
사실 학습로그를 작성하던 블랙잭 미션 당시에는 Service layer와 Dto가 크게 와닿지 않았다. 실질적으로 서비스레이어 개념을 깨달은건 체스 미션 중에 조이의 Controller-Service Layer 이야기를 들었을 때, 서비스레이어를 사용해본건 체스 미션 막바지 Dto 객체에 나도 모르게 서비스레이어에 포함될법한 메서드를 작성했던 것이다.
Dao에서는 데이터베이스에 직접 접근하는 대신 정말 기본적인 CRUD 행위만 수행하고, Service Layer에서 행위들의 순서를 제어하거나 조합해서 하나의 서비스 행위로 만들어낸다.
DTO에 관련해서는 인비의 테코톡을 정리한 글 을 참고하는게 나을거같다.
이벤트 버블링, 이벤트 캡처, 이벤트 위임
# [Javascript] 이벤트 버블링, 이벤트 캡처, 이벤트 위임 - 2
## 내용
- Javascript의 이벤트 범위와 버블링, 캡처를 이해하고 이벤트를 위임하는 방식에 대해 학습 후 적용함
## 링크
- https://joshua1988.github.io/web-development/javascript/event-propagation-delegation/
- https://github.com/woowacourse/java-chess/pull/240/files/5308f2fbc2149f2ccaf6db8a846b2f5e8669a02f#diff-bdbc4966c729e860f82b005ab3903fd146b59de79b1c7c168f8374b3381ada6e
JS 미션을 진행하는 동안 학습한 이벤트 버블링, 캡처, 위임.
이벤트 버블링은 작은 영역에서 발생한 이벤트가 상위 영역까지 퍼져나가는 것을, 이벤트 캡처는 상위 영역에서 발생한 이벤트를 작은 영역까지 침투하는 것을 의미한다. 그리고 퍼져나가고 침투한 이벤트를 잡아내서 처리하는 행위를 위임이라 부른다.
예를 하나 들어보자면.
To-do 리스트에 존재하는 아이템을 하나 클릭했을 때
그 이벤트 반응을 다른 아이템도 하는 경우를 이벤트 버블링이라 부른다.
반대로 To-do 리스트 제목을 클릭했을 때 To-do 리스트 내부 아이템이 반응하는 경우를 이벤트 캡처라 부른다.
댓글남기기