개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
유한 상태기계, 감시자패턴&게시 구독 모델,반응형프로그래밍을 통해 결합도를 낮추고 유연한 코드를 만든다.
상속세를 내지 않기 위해 우리는 인터페이스, 위임, 믹스인(&트레이트) 를 공부한다.
세부사항을 안전하고 쉽게 변경하는 방법 → 설정을 통해 완전히 코드 밖으로 옮긴다.
TIL (Today I Learned) 날짜
2022 - 05 -21
오늘 읽은 범위
5장. 구부러지거나 부러지거나
책에서 기억하고 싶은 내용을 써보세요.
코드를 쓰거나 이해하기 위해 객체가 알아야하는 것이 너무 많다.
모든 객체가 서로 연결되어 있듯이 메서드나 속성들이 모두 연결되어 있다. → 열차사고
묻지 말고 말하라. → 다른 객체 내부 상태에 따라 판단을 내리고 그객체를 갱신해서는 안된다.
데메테르 법칙
메서드 호출을 엮지 말라.
전역 데이터를 피하라.
싱글톤 패턴도 전역이다.
외부 리소스도 전역 데이터 입니다.
상속을 결합을 높인다.
이벤트 → 무언가 정보가 있다는 것을 의미
유한 상태기계
감시자 패턴 (옵저버 패턴)
module Terminator
CALLBACK = []
def self.register(callback)
CALLBACK << callback
end
def self.exit(exit_status)
CALLBACK.each{ |callback| callback.(exit_status)}
exit!(exit_status)
end
end
Terminator.register(->(status){puts "callback 1이 #{status} 관측"})
Terminator.exit(99)
#callback 1이 99 관측
감시자가 감시대상에 등록해야 되는 결합이 생긴다. -
게시구독(펍섭) 모델 → 감시자 패턴의 일반화
감시자 패턴과 다르게 통신이 코드밖에서 일어난다.(또 비동기적)
반응형 프로그래밍과 스트림 그리고 이벤트
스트림은 이벤트의 리스트로 보면 좋다.
변환 모델에서는 데이터를 전체시스템 여기저기 흩어놓는 대신, 데이터를 거대한 강으로 흐름으로 생각하라.
데이터는 기능과 동등해진다.(파이프라인은 코드 → 데이터의 연속)
프로그램이란 입력을 출력으로 바꾸는 것이라는 사고 방식으로 돌아갈 필요가 있다.
상속을 하게 되면 상속세를 내게 된다.(비용이 증가)
코드를 공유하기위해 상속을 쓸때의 문제점 → 결합이 너무 많다.
타입을 정의하기 위해 상속을 쓸때의 문제점 → 사소한 타입을 정의하기 위해 상속하게 되고 이런 복잡도는 앱을 더 취약하게 만든다.(다중상속 문제 → 제대로 모델링하기 힘듦)
해결책 → 인터페이스와 프로토콜, 위임, 믹스인과 트레이트
인터페이스와 프로토콜 → 상속없이도 다형성을 가져다 준다.
믹스인 → 기존의 것과 새로운 것의 기능 집합을 합치는 것(기능 공유)
위임 → 서비스에 위임하라. Has-A가 Is-A보다 낫다.
앱 출시 이후 바뀔수 있는 값은 앱 외부에서 관리하라.
정적 설정 더미
서비스 설정 - 설정 데이터를 동적으로 바꿀 수 있고(재빌드 할 필요가 없음) 각 컴포넌트가 설정값이 바뀔 때 알림을 보내 달라고 등록할 수 있다. 어떤 형태든 앱 실행시 설정 정보가 앱동작을 제어해야 된다.
도도 코드를 작성하지 마라.
환경에 적응하지 못하는 생물은 멸종한다.(유연성과 적응성이 코드에 필요하다.)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
토픽32와 관련하여 늘 설정을 외부 설정더미로 두어 설계했었는데, 서비스형 설정으로 변경하여 앱동작을 제어 해보고 싶다.
늘 객체지향공부를 하다보면 상속과 그 비용, 트레이드 오프에 대해 공부한다. 이번 상속세를 통해 다시 한번 상기 할 수 있어서 좋았고, 보통 인터페이스,위임를 통해 설계했었는데 믹스인(트레이트)를 좀더 공부해보고 싶었다.
결합도를 줄이고 응집도를 높이려는 생각은 설계에서 늘 해야되는 기본값 같다.
변화에 유연한 코드를 만드는 개발자가 된다는 것은
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
변환형 프로그래밍 토픽은 너무 어려웠다. 다시 읽어봐야 할 토픽이다.
오늘 읽은 다른사람의 TIL