실용주의 프로그래머 #05. 구부러지거나 부러지거나
🌟 책에서 기억하고 싶은 내용을 써보세요.
Topic28 결합도 줄이기
- 소프트웨어의 구조는 유연해야 한다. 그리고 유연하려면 각각의 부품이 다른 부품에 가능한 한 조금만 연결되어야 한다.
🛠️ Tip 44 결합도가 낮은 코드가 바꾸기 쉽다.
- 놓치면 안될 결합의 증상 (p.184)
- 관계없는 모듈이나 라이브러리 간의 희한한 의존 관계
- 한 모듈의 ‘간단한’ 수정이 이와 관계없는 모듈을 통해 시스템 전역으로 퍼져 나가거나 시스템의 다른 곳에서 무언가를 때뜨리는 경우
- 개발자가 수정하는 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우
- 변경 사항에 누가 영향을 받는지 파악하고 있는 사람이 없어서 결국 모든 사람이 참석해야 하는 회의
1. 열차 사고 : 연쇄 메서드 호출 (TPA)
열차 사고(train wreck) 코드란?- 기차의 모든 객차가 서로 연결되어 있듯이 메서드나 속성들이 모두 연결되어 있는 코드. (p.185)
🛠️ Tip 45 묻지 말고 말하라. Tell, Don’t Ask **
- TDA 원칙 (p.186)
- 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것.
- 내부 상태를 물어본다면? → 캡슐화의 장점이 사라짐! + 구현에 대한 지식이 코드 여기저기로 퍼져 버린다.
- 보편적인 최상위 개념들은 노출하는 것도 괜찮다. (실용적인 판단으로) p.187
[데메테르 법칙]
🛠️ Tip 46 메서드 호출을 엮지 말라.
- 무언가에 접근할 때 “.”을 딱 하나만 쓰려고 노력해 보라.
- 점 하나 규칙에는 큰 예외가 하나 있다. 엮는 것들이 절대로 바뀌지 않을 것 같다면 이 규칙을 지키지 않아도 된다.
[연쇄와 파이프라인]
- 파이프라인
- 함수에서 함수로 데이터를 넘겨 가며 데이터를 변환한다.
- 숨겨진 구현 세부 사항에 의존하지 않기 때문에 열차 사고와는 다르다.
- 파이프라인의 함수에서 반환하는 데이터는 반드시 다음 함수가 처리할 수 있는 형식이어야 하기 때문에 결합이 있긴 함. (p.189)
2. 글로벌화 : 정적인(static) 것의 위험함
- 전역(global) 데이터
- 전역 데이터 하나하나는 애플리케이션의 모든 메서드에 갑자기 매개 변수가 추가된 것과 같은 효과를 낸다.
- 문제점 1. 전역 데이터의 구현을 변경할 때 바꿔야 하는 곳을 모두 바꿨는지 확인하기 힘들다는 데 있다. (p.190)
- 문제점 2. 전역 데이터는 코드를 떼어 내는 경우에도 문제를 만든다.
[싱글턴도 전역 데이터다]
- 여러분의 코드에 있는 것이 싱글턴뿐이더라도, 외부로 노출된 인스턴스 변수가 잔뜩 있는 싱글턴은 여전히 전역 데이터이다.(p.191)
[외부 리소스도 전역 데이터다]
- 수정 가능한 외부 리소스는 모두 전역 데이터다.
- 데이터베이스나 저장소, 파일 시스템, 서비스 API 등
- 해법 : 리소스들을 여러분이 작성하는 코드로 모두 감싸는 것이다. (p.191)
🛠️ Tip 48 전역적이어야 할 만큼 중요하다면 API로 감싸라.
3. 상속 : 왜 클래스 상속이 위험한가
→ 상속은 결합을 늘린다.(Topic31. 상속세와 연결)
결국은 모두 ETC (Easy To Change)
- 직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 계속 유지하라
- 결합도를 낮게 유지할 수 있음 → 결과적으로 코드를 바꾸기 쉬어질 것이다. (p.192)
Topic29 실세계를 갖고 저글링하기
- 사람이 컴퓨터에 맞추기보다는 컴퓨터가 우리 세계 안으로 들어와야 한다. 그리고 우리 세계는 엉망이다. (이동/변화가 많음) ⇒ 반응적인(responsive) 애플리케이션이 필요. (이벤트)
이벤트
- 이벤트: 무언가 정보가 있다는 것을 의미 (p.193)
- 정보
- 사용자가 버튼을 클릭하거나 주가 정보가 갱신될 때처럼 외부에서 올 수 있다.
- 계산 결과가 나왔거나, 검색 작업이 끝나거나 리스트에서 다음 원소를 가져오는 등 내부에서 생길 수도 있다.
- 애플리케이션이 이런 이벤트에 반응하도록 만들면 진짜 세상에서 더 잘 작동하는 애플리케이션이 탄생할 것이다. (p.194)
- 이벤트에 잘 반응하는 애플리케이션을 만드는 네 가지 전략
- 유한 상태 기계
- 감시자Observer 패턴
- 게시-구독
- 반응형 프로그래밍과 스트림
유한 상태 기계 (FSM)
- 상태 기계: 이벤트를 어떻게 처리할지 정의한 명세
- 정해진 상태들이 있고 그 중 하나가 ‘현재 상태’다. 상태마다 그 상태일 때 의미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 ‘현재 상태’를 정의한다.
- FSM의 장점: 오로지 데이터만으로 FSM을 표현할 수 있다.(p.195)
- 행동을 추가하여 더 강력하게 만들 수 있다.
- 상태를 외부 저장소에 저장하면서 상태 기계를 동작시키면 작업 흐름이 필요한 요구 사항을 수월하게 처리할 수 있을 것이다. (p.199)
- 하지만 상태 기계가 이벤트와 관련된 모든 문제를 해결하지는 못한다 → 감시자 패턴
감시자 패턴
- 감시 대상과 감시자로 이루어 진다.
- 감시 대상: 이벤트를 발생시키는 쪽
- 감시자: 이런 이벤트에 관심이 있는 클라이언트
-
감시자는 자신이 관심 있는 이벤트를 감시 대상에 등록한다
→ 나중에 해당 이벤트가 발생하면 감시 대상은 등록된 감시자 목록을 보면서 함수들을 일일이 호출한다.
+) 이때, 발생한 이벤트를 감시자 함수의 인자로 넘긴다.
- 감시자 패턴의 문제 → 게시-구독
- 모든 감시자가 감시 대상에 등록을 해야 하기 때문에 결합이 생김
- 동기적 처리 특성상 콜백 실행이 끝날 때까지 감시 대상이 계속 기다려야 하기 때문에 성능 병목이 될 수 있다.
댓글남기기