TIL (Today I Learned)
2022.03.26
오늘 읽은 범위
5장. 구부러지거나 부러지거나
🎨 책에서 기억하고 싶은 내용을 써보세요.
-
182p
높은 결합도는 변경의 적이다.
결합도가 높으면 이리저리 연결되어 있어서 여러 가지를 동시에 바꿔야 하기 때문이다.
그래서 바꾸기 더 어려워진다. 여러분의 운명은 둘 중 하나다.
바꿔야 하는 곳을 모두 찾아내느라 시간을 들이거나, 아니면 ‘딱 하나만’ 바꾸고 결합 된 다른 것들은 잊은 채 왜 프로그램이 죽는지 고민하느라 시간을 들이거나.
결합도를 줄이는데 그렇게까지 경각심을 가지고 있지 않았는데 이것을 보니 그냥 줄이기만 하는게 중요한게 아니라 전체적인 앱의 구조를 설계하는게 엄청 중요한 것같다.
-
185p
기차의 모든 객차가 서로 연결되어 있듯이 메서드나 속성들이 모두 연결되어 있다.
이런 코드를 ‘열차 사고’라고 부른다.
묻지 말고 말하라Tell, Don’t Ask, TDA.
이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해 서는 안 된다는 것이다
객체의 내부 상태를 묻는 것으로 인하여 캡슐화 (encapsulation)의 장점은 완전히 사라지고, 또 그 과정에서 구현에 대한 지식이 코드 여기저기로 퍼져 버린다.
이걸 너무 쫓아간다면 함수가 너무 많아질거같은 생각이 들었는데 안그래도 책에서 이건 패턴일뿐 법칙이 아니라해서 판단을 내릴때 한결 편해질것같다.
-
188p
메서드 호출을 엮지 말라.
무언가에 접근할 때 “.”을 딱 하나만 쓰려고 노력해 보라
그럼 어떻게 하라고? 🤔
엮이는 것들이 절대로 바뀌지 않을 것 같다면 이 규칙을 지키지 않아도 된다고 한다.
근데 여기서 의문점은 대부분 이런 접근법을 사용할떄는 메서드들이 바뀔 가능성이 없을 수가 없는데 이 방법은 이해는 했지만 현실적으로 사용하기 힘들 것 같다.
이벤트가 잘 작동하기 위한 전략 4가지
-
194p
1번 유한상태기계 (Finite State Machine, FSM)
정해진 상태들이 있고 그중 하나가 ‘현재 상태’다. 상태마다 그 상태일 때 의 미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 ‘현재 상태’를 정 의한다.
FSM의 멋진 점은 FSM을 오로지 데이터만으로 표현할 수 있다는 것이다.
출력은 최종 '상태'일뿐 여기에 특정한 상태 이행이 일어날 떄 수행하는 행동을 추가하여 FSM을 더 강력하게 만들 수 있다.
내가 생각했을때는 그냥 미들웨어의 역할을 해주는 것 같다.
상태의 처리는 에러나 성공이나 둘 중하나로 결과가 나오고 넘어가야하며 미들웨어를 추가함으로 더 강력한 FSM을 만들 수 있는 걸로 이해했다. -
199p
이벤트를 발생시키는 쪽인 ‘감시 대상observable’과 이런 이벤트에 관심이 있는 클라이언트인 ‘감시자’로 이루어진다
모든 감시자가 감시 대상에 등록을 해야 하기 때문에 결합이 생긴다.
더군다나 일반적으로 감시 대상이 콜 백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다.
동기적synchronous 처리의 특성상 콜백 실행이 끝날 때까지 감시 대상이 계속 기다려야 하기 때문이다.
이러한 문제는 게시-구독으로 해결한다.
-
201p
게시-구독 : 감시자 패턴을 일반화한 것이다. 동시에 감시자 모델의 결합도를 높이는 문제와 성능 문제도 해결한다.
게시자와 구독자 사이의 통신은 여러분의 코드 밖(게시자와 구독자를 연결시켜주는 채널)에서 일어난다. 아마 비동기적으로 이루어질 것이다.
그냥 비동기 처리를 이벤트 하나마다 연결시켜서 한다는 뜻으로 이해했는데 제대로 된 이해인지 모르겠다.
-
207p
프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다.
진짜 책에서 말한대로 난 이것에 대해 망각하고 있었다. 리액트가 어떻게 작동하는지 다른 라이브러리들이 어떤 방식으로 돌아가는지만 공부하고 있었고 그런것에 대한 생각은 알고리즘을 풀때만 생각했었다.
-
216p
데이터를 거대한 강으로, 흐름으로 생각하라. 데이터는 기능과 동등해진다. 파이프라인은 코드 → 데이터 → 코드 → 데이터......의 연속이다.
데이터는 더 이상 클래스를 정의할 때처럼 특정한 함수들과 묶이지 않는다.
대신 우리 애플리케이션이 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다.
이 말인 즉슨 결합을 대폭 줄일 수 있다는 것이다.
어떤 함수든 매개 변수가 다른 함수의 출력 결과와 맞기만 하면 어디서나 사용하고 또 재사용할 수 있다.
어느 정도의 결합은 존재한다.
-
217p
변환 사이에 값을 절대 날것으로 넘기지 않는 것이다.
대신 래퍼wrapper 역할을 하는 자료 구조나 타입으로 값을 싸서 넘긴다. 이런 자료 구조나 타입 은 안에 들어 있는 값이 유효한지를 추가로 알려 준다
데이터의 결합구조를 나누고 입출력에 대한 관리만 이루어진다면 함수의 결합도는 더 낮아지고 간결해질것같다.
-
233p
클래스나 객체에 상속을 사용하지 않고 새로운 기능을 추가하여 확 장하고 싶다.
그래서 일련의 함수들을 만들고, 여기에 이름을 붙인 다음, 이 것으로 어떻게든 클래스나 객체를 확장한다.
이 시점에서 여러분은 기존 클 래스와 그에 덧붙이는 믹스인의 동작을 모두 합한 새로운 클래스나 객체를 만든 것이다.
중요한 것은 이 기능 을 구현했을 때 할 수 있는 일, 바로 기존의 것과 새로운 것의 기능 집합을 합 치는 것이다.
mixin
mixin CommonFinders { def find(id) { ... } def findAll() { ... }
}
class AccountRecord extends BasicRecord with CommonFinders
class OrderRecord extends BasicRecord with CommonFinders클래스에―비즈니스 객체 혹은 영속성 객체 의 클래스에―모든 검증을 다 가져다 붙인 후, 상황별로 플래그를 추가해서 적용할 검증 사항을 관리하는 것이다. 별로 이상적이지는 않다.
검증
class AccountForCustomer extends Account
with AccountValidations,AccountCustomerValidations
class AccountForAdmin extends Account
with AccountValidations,AccountAdminValidations-
238p
어떤 형태를 사용하든지 애플리케이션을 실행시켰을 때 설정 정보가 애플 리케이션의 동작을 제어해야 한다. 설정 정보를 바꾸기 위해 코드 빌드가 필요해서는 안 된다.
🍋 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
클래스에 대한 인식이 많이 바뀌게 된 계기가 되었고 앞으로 함수만 생각해서 코드의 결합도를 낮추는게 아니라 입력값과 함수가 내뱉는 출력값 데이터를 기준으로 생각해야겠다.
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
추이적 (transitive) : x가 y와 관계가 있고 y가 z와 관계가 있으면, x가 z와 관계가 있는. 또는 그런 것
싱글턴 (singleton) : 객체의 인스턴스가 오직 1개만 생성되는 패턴
https://devmoony.tistory.com/43
