[TIL] 5장 구부러지거나 부러지거나

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

오늘의 TIL 3줄 요약

• 결합도를 줄이기 위한 방법
• 상속을 맹목적으로 하지 말아야 하는 이유
• 프로그램과 분리해야하는 것을 명확하게 정할 것

1. 책에서 기억하고 싶은 내용

[28. 결합도 줄이기] - 관계없는 개념들을 분리하여 결합도를 낮추는 방법
결합에 대한 증상
  1) 관계없는 모듈이나 라이브러리 간의 희한한 의존 관계
  2) 한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스템 전역으로 퍼져 나가거나 시스템의 다른 곳에서 무언가를 깨뜨리는 경우
  3) 개발자가 수정하는 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우
  4) 변경 사항에 누가 영향을 받는지 파악하고 있는 사람이 없어서 결국 모든 사람이 참석해야 하는 회의
우리는 이러한 결합의 증상들을 놓치면 안 된다.

열차사고 : 기차의 모든 객차가 서로 연결되어 있듯이 메서드나 속성들이 모두 연결되어 있다.
메서드 호출을 엮지 말라. 무언가에 접근할 때 "."을 딱 하나만 쓰려고 노력해 보라. '무언가에 접근'한다는 건 중간 변수를 사용하는 경우까지 포함해야 한다. 점 하나 규칙에는 큰 예외가 하나 있다. 엮는 것들이 절대로 바뀌지 않을 것 같다면 이 규칙을 지키지 않아도 된다.

코드 재사용의 장점은 많이 알려져 있다. 코드를 처음 작성하는 시점의 제1관심사가 코드 재사용이어서는 안 될 것이다. 하지만 우리의 경험에 비추어 볼 때 코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관의 일부가 되어야 한다.

전역 데이터를 피하라 - 싱글턴도 전역 데이터다.
여러분의 코드에 있는 것이 싱글 턴 뿐이더라도, 외부로 노출된 인스턴스 변수가 잔뜩 있는 싱글턴은 여전히 전역 데이터다.
전역 데이터를 피하라 - 외부 리소스도 전역 데이터다.
전역적이어야 할 만큼 중요하다면 API로 감싸라.

[29. 실세계를 갖고 저글링하기] - "이벤트"의 관리 및 대응하는 전략 
이벤트 : 무언가 정보가 있다는 것을 의미.

이벤트에 잘 반응하는 애플리케이션을 만들기 위한 전략
  1) 유한 상태 기계
    - 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세이다. 
    - 정해진 상태들이 있고 그중 하나가 '현재 상태'다.
    - 상태마다 그 상태일 때 의미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 '현재 상태'를 정의한다.
  2) 감시자 패턴
    - observer pattern은 이벤트를 발생시키는 쪽인 observable과 이런 이벤트에 관심이 있는 클라이언트인 observer로 이루어진다.
    - '감시자-감시대상' 패턴은 수십 년간 쓰여 왔고, 잘 작동했다. 특히 사용자 인터페이스 시스템에서 널리 쓰이는데, 어떤 상호 작용이 일어났다는 것을 애플리케이션에 콜백으로 알려주는 방식을 사용한다.
    - 모든 감시자가 감시 대상에 등록해야 하기 때문에 결합이 생기고, 일반적으로 감시 대상이 콜백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다. 해당 문제는 '게시 - 구독'으로 해결한다.
  3) 게시 - 구독
    - 'publish - subscribe' / '발행 - 구독'
    - 감시자 패턴을 일반화 한 것.
    - 게시자와 구독자가 있고, 이들은 채널로 연결된다. 채널은 별도의 코드로 구현되는데 라이브러리인 경우도 있고 프로세스 혹은 분산 인프라인 경우도 있다.
    - 추가적인 결합 없이 비동기 이벤트 처리를 구현하기에 아주 좋은 기술이다. 다른 기존 코드를 수정하지 않고 이벤트 처리 코드를 추가하거나 교체할 수 있다.
  4) 반응형 프로그래밍과 스트림
    - 이벤트를 사용하여 코드가 반응하도록 할 수 있다는 것은 명백하다.
    - 하지만 이벤트를 이리저리 연결하는 것도 쉽지 않다. 그래서 '스트림'이 필요하다.
    - 스트림은 이벤트를 일반적인 자료 구조처럼 다룰 수 있게 해 준다.

[30. 변환 프로그래밍] - 함수 파이프
자신이 하고 있는 걸 하나의 과정으로 서술할 수 없다면, 자기가 뭘 하고 있는지 모르는 것이다. -에드워즈 데밍

프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다.
프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.

객체 지향 프로그래밍 경험이 많다면 반사적으로 데이터를 숨기고, 객체 안에 캡슐화해야 한다고 느낄 것이다. 이러한 객체들은 서로 이리저리 이야기하며 서로의 상태를 변경한다. 이런 방식은 결합을 많이 만들어 내고, 이는 결국 객체 지향 시스템이 바꾸기 어려워지는 큰 요인이 된다.
상태를 쌓아 놓지 말고 전달하라.

[31. 상속세] - 유연하고 바꾸기 쉬운 코드를 만들 수 있는 더 나은 대안
객체 지향 개발자 세대는 다음 둘 중 하나의 이유로 상속을 사용한다. 타입이 싫어서 아니면 타입이 좋아서.

상속을 쓸 필요가 없게 해 주는 세 가지 기법
 1) 인터페이스와 프로토콜
    - 다형성은 인터페이스로 표현하는 것이 좋다.
    - 인터페이스와 프로토콜은 상속 없이도 다형성을 가져다준다.
 2) 위임
    - 서비스에 위임하라. Has-A가 Is-A보다 낫다.
 3) 믹스인과 트레이트

[32. 설정]
애플리케이션이 출시된 이후 바뀔 수도 있는 값에 코드가 의존하고 있다면 그 값을 애플리케이션 외부에서 관리하라.
일반적으로 설정 데이터 안에 넣는 것
 1) 데이터베이스나 외부 API 같은 외부 서비스의 인증정보
 2) 로그 레벨과 로그 저장 위치
 3) 애플리케이션이 사용하는 포트번호, IP주소, 기계나 클러스터 이름
 4) 특정 실행 환경에만 적용되는 검증 매개 변수
 5) 외부에서 지정하는 매개변수
 6) 지역에 따른 세부 서식
 7) 라이선스 키

2. 궁금한 내용과 잘 이해되지 않은 내용에 대한 정리

@믹스인과 트레이트
참조 블로그 : 코드 재사용을 위한 Mixin