DAY 9 (p.207-266 전자책기준)

5장.구부러지거나 부러지거나 Bend, or Break

📚 오늘 TIL 3줄 요약

• 전역 데이터를 피하라
• 상속세를 내지 마라!
• 적응성, 유연성을 포기하는 멸종 코드를 작성하지 말라

기억하고 싶은 내용

결합도 줄이기

• 적게 연결된 코드가 바꾸기 쉽다

• 열차사고
  메서드와 속성들이 모두 연결되어 있는 것

• 묻지 말고 말하라 Tell, Don't Ask. TDA

• 데메테르 법칙 Law of Demeter. LoD
  .점 하나로 엮어지는 것은 바뀌리라 생각해라

// 좋지 않다
amount = customer.orders.last().totals().amount;

• 전역 데이터를 피하라
  코드의 결합도를 높이고, 코드를 떼어내는 경우에도 문제가 발생한다
  -싱글턴도 전역 데이터다
  -외부리소스도 전역 데이터다
  
  

실세계를 갖고 저글링하기

이벤트

1. 유한 상태 기계 Finite State Machine. FSM

2. 감시자 패턴 Observer Pattern
   이벤트 발생시키는 감시대상과 이벤트에 관심있는 클라이언트 감시자로 이뤄진다
   감시자가 감시대상에 등록해야하는 결함발생.
   감시대상이 콜백 직접호출하므로, 동기적 특성상 감시대상이 계속 기다려야한다
   이 문제는 3. 게시 구독으로 해결한다

3. 게시 구독 pubsub
   감시자 패턴을 일반화한 것 + 높은 결합도, 성능 문제 해결

• 게시자publishe와 구독자subscribe가 채널channel로 연결
• 채널은 별도의 코드(라이브러리, 프로세스, 분산 인프라 등)로 구현된다
• 게시자와 구독자 사이의 통신은 코드 밖에서 이뤄지고 비동기적일 것이다
• 대부분 클라우드 서비스가 pubsub서비스 제공한다
• 추가적인 결합 없이 비동기 이벤트 처리하기 좋은 기술이다
• 기존코드의 수정없이 이벤트 처리 코드를 추가, 교체할 수 있다
• <단점> 해당 시스템에서 현재 어떤 일이 발생하는 지 파악하기 힘들다

4. 반응형 프로그래밍과 스트림 그리고 이벤트

   • 반응형 프로그래밍
     값이 바뀌면 그 값은 참조한 다른 값이 반응하는 것
     ex) React, Vue

   • 스트림 Stream
     이벤트를 일반적인 자료구조처럼 다룰 수 있게 한다
     이벤트를 처리, 조합, 골라내는 등의 작업을 자료구조와 같은 방법으로 할 수 있다
     비동기적으로 작동 가능
     이벤트스트림은 이벤트가 발생할 때마다 생성된다
     이벤트스트림은 동기적, 비동기적 처리를 공통 API로 감싸서 통합한다
     
     
     

변환 프로그래밍

Q . 폴더 안 파일 중에 줄 수가 가장 긴 파일 5개 찾는 프로그램 작성해주시오.

$ find . -type f | xargs wc -l | sort -n | tail -6 | head -5
디렉터리 이름
-파일명 목록 find
-줄 수와 파일명 목록 wc
-정렬된 목록 sort
-가장 긴 것 5개와 전체 줄 수 tail
-가장 긴 것 5개 head

• 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다

• 변환 찾기
  하향식 접근 - 입력을 출력으로 바꿔가기
  ex) Elm, F#, 스위프트 |>, 클로저 ->와 ->>, R은 %>%
  
  

Q . 몇 개의 알파벳으로 3,4글자 단어 목록 생성하기

word
|> all_subsets_longer_than_three_characters()
|> as_unique_signatures()
|> find_in_dictionary()
|> group_by_length()

요구사항 달성을 위해 앞 변환에서 입력을 받아 처리한 결과를 다음 변환으로 넘겨준다. 하지만 객체 지향 프로그래밍 경험이 많다면 데이터를 숨기고 객체안에 캡슐화한다고 느낄 것이다. 이런 객체들은 서로 상태를 변경하므로 결합도가 높아져 변경하기 어려운 요인이 된다. 그런데 변환에선 이런 사고를 뒤엎는다

• 상태를 쌓아 놓지 말고 전달하라
  -데이터를 거대한 흐름으로 생각하라. 데이터는 기능과 동등해진다
  -어떤 함수든 매개 변수가 다른함수의 출력결과와 맞다면 어디서나 재사용 가능해진다

오류처리

변환 사이에 값을 날 것으로 넘기지 않고, 래퍼역할을 하는 자료구조나 타입으로 값을 싸서 넘기기
- 표현 방식 정하기
- 각 변환 내에서 오류 처리
- 파이프라인에서 오류 처리

• 변환은 프로그래밍을 변환한다
  코드가 명확해지고 함수는 짧아지고 설계는 단순해지니 한번 해 봐라.

상속세

• 상속
  1. 시뮬라 : 타입을 조합하는 방법 ex)C++, Java
  2. 스몰토크: 동작을 다양하게 구성하는 방법 ex)Ruby, JS
  

• 객체 지향 개발자가 상속을 사용하는 이유
  1. 타입싫어서 = 입력하는 글자 수 줄이려고, 부모-자식 클래스로 넘김
  2. 타입좋아서 = 상속으로 클래스 간 관계를 표현한다
  === 이 두가지 모두 문제있음
  ==> 1은 결합도 문제, 2는 다중상속 문제

• 상속세를 내지마!

<상속 필요 없는 이유>
1. 인터페이스와 프로토콜 : 상속없이도 다형성 가져다준다
2. 위임 :
3. 믹스인, 트레이트, 카테고리, 프로토콜 확장 등

• 정글 전체를 끌어들이지 않도록 조심하라

외부 설정

• 바뀔 것들은, 소스코드 밖인 외부 설정으로 어플리케이션을 조정할 수 있게 하라
• 어플리케이션 실행 시, 설정정보가 어플 동작을 제어해야한다.

<설정데이터 안에 들어가는 것>

• DB나 외부 API같은 외부 서비스의 인증정보
• log 레벨과 log 저장 위치
• 어플리케이션이 사용하는 포트번호, IP주소, 기계나 클러스터명
• 특정 실행 환경에만 적용되는 검증 매개 변수
• 외부에서 지정하는 매개변수, 예로 배송비
• 지역에 따른 세부 서식
• 라이선스 키

정적 설정

YAML, JSON

• 설정 정보를 얇은 API 뒤로 숨겨라. 그러면 세부사항으로부터 여러분의 코드를 떼어 놓을 수 있다

서비스형 설정

우리는 서비스 API 뒤에서 관리하는 것을 선호한다

• 장점
  - 여러 어플리케이션이 설정정보 공유가능. 인증과 접근제어를 붙여 어플리케이션마다 보이는 정보 다르게 만들 수 있다
  - 여러 인스턴스에 걸쳐 전체 설정을 한번에 변경 가능
  - 설정 데이터를 전용 UI로 관리 가능
  - 설정 데이터를 동적으로 계속 변경 가능

소감

유한 상태 기계p.218부분이 잘 이해가 안가서 나중에 다시 읽어봐야 겠다. 변환에 대한 부분도 명확하게 이해하진 못했다. 계속 다시 읽어보고 자료를 찾아야겠다. 그리고 상속하지 않는 것과 결합을 낮추는 방법을 다시 한 번 인지하게 됐고 외부설정에 대한 필요성도 느끼게 됐다. 이론적으론 적용에 필요성을 알게 됐는데 막상 어떻게 적용해야 될지는 감조차 오지 않는다. 이 몫도 앞으로 해나가야할 과제로 생각했다. 일단은 책에서 말하는 필요준비물들을 주구절절 요약해나가고 있는 TIL인데, 나중에 내 TIL을 봤을 때 키워드를 중심으로 하나씩 직접 실전에 적용해봐야 이 책이 큰 밑거름이 될 것으로 생각한다. 솔직히 아직까진 어떻게 하는지 모르겠다. 마치 문제풀이를 모르는 것같은 기분이다. 그래도 앞으로 차근차근 하는 수 밖에.. 파이팅

궁금한 내용, 잘 이해되지 않는 내용은?

• 싱글턴 p.217
• FSM 유한상태기계 p.218~
• 스트림 관련 사용예제
• 파이프라인
• 변환 프로그래밍

오늘 읽은 다른 사람의 TIL

• roxy님의 TIL