실용주의 프로그래머(The Pragmatic Programmer) 챌린지 6일차 TIL

오늘 TIL 3줄 요약

 

TIL 날짜

- 2022-03-26

오늘읽은 범위

- 5장. 구부러지거나 부러지거나

책에서 기억하고 싶은 내용

결합도 줄이기

높은 결합도는 변경의 적이다 따라서 소프트웨어의 구조는 유연해야 한다.

결합도가 높아지는 대표적 사례

1. 열차 사고 : 메서드와 속성들이 모두 연결되어 있다 => 묻지 말고 답하라. TDA(Tell, Don't Ask)

다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안된다는 것

데메테르 법칙(Law of Demeter) : 메서드 호출을 엮지 말라 = 무언가에 접근할때 "." 을 딱 하나만 쓰려고 노력하라.

2. 글로벌화 : 전역데이터를 피하라 / 전역 데이터 하나는 애플리케이션의 모든 메서드에 갑자기 매개 변수가 추가된 것과 같은 효과를 낸다.

싱글턴도 전역 데이터다.

전역적이어야 할 만큼 중요하다면 API로 감싸라

3. 상속 : 상속은 다른 클래스의 상태와 행동을 그대로 가져올 수 있다.

결국은 ETC = 직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 유지하라.

 

실세계를 갖고 저글링하기

1. 반응형 어플리케이션 (유한 상태 기계 FSM)

- 이벤트(event) : 무언가 정보가 있음을 의미하는 것 / 상태마다 의미가 있는 이벤트들이 있고, 그 이벤트마다 다음 현재 상태가 정의되어 있다.

- 상태(state) : 현재 상태

- 행동(action) : 특정한 상태 이행이 일어날 때 수행하는 행동

 

2. 감시자 패턴

- 감시 대상 (observable) : 이벤트가 발생하면 등록된 감시자 목록을 보면서 함수들을 일일이 호출, 발생한 이벤트를 감시자 함수의 인자로 넘긴다.

- 감시자 (observer) : 자신이 관심 있는 이벤트를 감시 대상에 등록한다.

모든 감시자가 감시 대상에 등록을 해야하기 때문에 결함이 생긴다. 감시 대상이 콜백을 직접 호출하도록 구현되기 때문에 성능 병목이 될 수 있다.

 

3. 게시 구독 (pubsub) - 아마 유니티에서 사용하는 방식인 듯하다?(EventListener)

- 게시자(publisher) : 감시 대상

- 구독자(subscriber) : 감시자

- 채널(channel) : 우리의 코드 밖에서 비동기적으로 게시자와 구독자를 연결

감시자 패턴보다 결함도를 줄였지만 메시지 전달 시스템에 불과하다.

 

4. 반응형 프로그래밍 / 스트림 / 이벤트

- 반응형 프로그래밍 : 값이 바뀌면 그값을 사용하는 다른값이 반응하는 것

- 스트림 : 이벤트의 리스트

이벤트를 일반적인 자료구조처럼 다루게 만든다.

 

변환 프로그래밍

프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.(프로그램 = 입력을 출력으로 바꾸는 것)

파이프라인이 없는 언어의 경우 => 변환으로 코드를 구성하면 된다. 단계마다 임시 const 변수에 값을 저장

상태를 쌓아 놓지 말고 전달하라

 

상속세

상속세를 내지 말라

클래스 상속의 대안

1. 다형성은 인터페이스로 표현하는 것이 좋다.(인터페이스)

2. 서비스에 위임하라. HAS-A 가 IS-A 보다 낫다.(위임)

3. 믹스인으로 기능을 공유하라.(믹스인)

상속이 답인 경우는 드물다.

 

설정

외부 설정으로 애플리케이션을 조정할 수 있게 하라(YAML, JSON)

도도 코드(외부 환경의 변화에 따라 사라지는 코드)를 작성하지 말라

오늘 읽은 소감 / 떠오르는 생각

오늘이 지금까지의 챌린지 과정중에 가장 힘든 날이지 않나 싶다. 처음 읽을때는 이해가 되질 않아서, 뒤에서부터 다시 읽어보니 각 토픽별로 쉬운부분들은 이해가 겨우 된듯 하다. 내가 얼마나 부족한지 다시한번 깨달을 수 있었다.

또 Elixer 라는 함수형 프로그래밍 언어를 처음 접했는데 왜 함수형 언어가 새로운 패러다임으로 각광받는지 알 수 있었던것 같다.

궁금한 내용

오늘 내용은 솔직히 이해하기 힘든 부분이 많았던것 같다.

- 변환프로그래밍의 오류처리

- 

이틀간 복습기간에 좀더 공부를 하도록 하자!