실용주의 프로그래머 #9일차

요몇일 컨디션이 좋지못해 포스팅이 좀 지체되었다.. ㅠㅠ

 

 

🧑🏻‍💻 오늘 TIL 3줄 요약

 

• 유연함을 유지하는 한 가지 좋은 방법은 물론 가능한 한 코드를 적게 작성하는 것이다.

 

• 코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관의 일부가 되어야 한다.

 

• 어렵다. 이 챕터는 최소 3회이상 반복해서 정독 해야겠다.

 

TIL (Today I Learned)

 

• 2022. 3. 28.

 

📕 오늘 읽은 범위

 

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

 

🙂 책에서 기억하고 싶은 내용

 

• 유연함을 유지하는 한 가지 좋은 방법은 물론 가능한 한 코드를 적게 작성하는 것이다. _p.182

 

Topic28. 결합도 줄이기

 

• Tip44. 결합도가 낮은 코드가 바꾸기 쉽다. _p.184
• Tip45. 묻지 말고 말하라 Tell, Don't Ask, TDA. _p.186
• Tip46. 메서드 호출을 엮지 말라. _p.188
• 무언가에 접근할 때 "."을 딱 하나만 쓰려고 노력해 보라.
• 코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관의 일부가 되어야 한다. 코드를 재사용할 수 있게 하려면 깨끗한 인터페이스를 만들고 나머지 코드와의 결합을 없애야 한다. _p.190
• Tip47. 전역 데이터를 피하라. _p.190
• 싱글턴, 외부 리소스도 전역 데이터다 _p.191
• Tip48. 전역적이어야 할 만큼 중요하다면 API로 감싸라. _p.191

 

Topic29. 실세계를 갖고 저글링하기

 

    1. 유한 상태 기계

• 기본적으로 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세일 뿐이다. 정해진 상태들이 있고 그중 하나가 ‘현재 상태’다. 상태마다 그 상태일 때 의 미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 ‘현재 상태’를 정 의한다. _p.195
• 하지만 상태 기계가 이벤트와 관련된 모 든 문제를 해결하지는 못한다. _p.199

 

    2. 감시자observer 패턴

•  감시자는 자신이 관심 있는 이벤트를 감시 대상에 등록한다. 보통은 호출 될 함수의 참조도 등록할 때 함께 넘긴다. 나중에 해당 이벤트가 발생하면 감 시 대상은 등록된 감시자 목록을 보면서 함수들을 일일이 호출한다. 이때, 발 생한 이벤트를 감시자 함수의 인자로 넘긴다. _p.199
•  하지만 감시자 패턴에는 문제가 하나 있다. 모든 감시자가 감시 대상에 등 록을 해야 하기 때문에 결합이 생긴다. 더군다나 일반적으로 감시 대상이 콜 백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다. _p.200

 

    3. 게시-구독

• 게시-구독 모델은 추가적인 결합 없이 비동기 이벤트 처리를 구현하기에 아주 좋은 기술이다. 다른 기존 코드를 수정하지 않고 이벤트 처리 코드를 추가하거나 교체할 수 있다. 애플리케이션이 작동하고 있는 도중에 작업이 가 능할 수도 있다. 대신 단점은 게시-구독 모델을 아주 많이 사용하는 시스템에서는 현재 어떤 일이 벌어지고 있는지 파악하기가 힘들다는 것이다. 게시자가 메시지를 보내는 것을 확인했더라도 어떤 구독자가 그 메시지를 처리하는지 바로 이어서 볼 수 없다. _p.201

 

    4. 반응형 프로그래밍과 스트림

•  이벤트를 사용하여 코드가 반응하도록 할 수 있다는 것은 명백하다. 하지 만 이벤트를 이리저리 연결하는 것도 쉽지만은 않다. 그래서 ‘스트림stream’이 필요하다. _p.202
•  스트림은 이벤트를 일반적인 자료 구조처럼 다룰 수 있게 해 준다. 이벤트 의 리스트를 다룬다고 생각하면 된다. 새로운 이벤트가 도착하면 이 리스트 가 길어지는 셈이다. 이런 방식이 좋은 이유는 익숙한 방식으로 스트림을 다 룰 수 있기 때문이다. 이벤트를 처리하고, 조합하고, 골라내는 등 우리가 아 는 온갖 작업을 일반적인 자료 구조와 마찬가지 방법으로 할 수 있다. _p.202

 

 

Topic30. 변환 프로그래밍

 

• Tip49. 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다. _p.210
•  요구 사항에서 시작하는 게 변환을 찾는 가장 쉬운 방법이다. 요 구 사항에서 입력과 출력이 무엇인지 찾으면 전체 프로그램을 나타내는 함수 가 정해진다. 이제 입력을 출력으로 바꿔 가는 단계들을 찾으면 된다. 일종 의 ‘하향식top-down’ 접근 방식이다. _p.210
• 파이프라인은 탄생한 지 꽤 오래되긴 했지만, 사용자가 많지 않은 언어에서만 쓰였다. 주류로 부상한 것은 최근이고, 널리 쓰이는 언어들은 대부분 아직 이런 개념을 지원하지 않고 있다.
  하지만 실망하지 않아도 된다. 변환을 중심으로 생각하는데 언어의 특별한 문법이 꼭 필 요하지는 않다. 사실 변환 프로그래밍은 설계 철학에 가깝다. 변환으로 코드를 구성하면 된 다. 다만 단계마다 임시 변수에 값을 저장해야 할 뿐이다. _p.215
• Tip50. 상태를 쌓아 놓지 말고 전달하라. _p.216

 

Topic31. 상속세

 

•  객체 지향 언어로 프로그래밍하는가? 상속을 사용하는가?
  그렇다면 멈춰라! 아마 여러분에게 필요한 것은 상속이 아닐 것이다. _p.224
•  코드를 공유하기 위해 상속을 쓸 때의 문제
  상속도 일종의 결합이다. 자식 클래스가 부모 클래스, 부모의 부모, 또 그 부 모에게 연결되는 것은 물론이요, 자식 클래스를 사용하는 코드도 이 클래스 의 모든 조상과 얽히게 된다. _p.226
• C++는 1990년대에 다중 상속에 오명을 씌웠다. C++의 모호성 해소 방식에 의심스러운 부분들이 있었기 때문이었다. 그 결과 이제는 많은 객체 지향 언 어에서 다중 상속을 지원하지 않는다. 따라서 아무리 복잡한 클래스 계층도가 마음에 들더라도 어차피 여러분의 도메인을 정확하게 모델링할 수는 없다. _p.228
• Tip51. 상속세를 내지 말라.

    * 상속을 대체할 3가지 기법 _p.229

• 인터페이스와 프로토콜
• 위임
• 믹스인과 트레이트
• Tip52. 다형성은 인터페이스로 표현하는 것이 좋다.
• Tip53. 서비스에 위임하라. Has-A 가 Is-A 보다 낫다. _p.232
• Tip54. 믹스인으로 기능을 공유하라. _p.235
• 여러분의 상황에 따라 더 나은 방법이 있을 것이다. 타입 정보를 공유하고 싶 은 건지, 기능을 더하고 싶은 건지, 메서드를 공유하고 싶은 건지에 따라 다 르다. 프로그래밍의 다른 모든 것과 마찬가지로 여러분의 목표는 의도를 가 장 잘 드러내는 기법을 사용하는 것이어야 한다. _p.235

 

Topic32. 설정

 

• Tip55. 외부 설정으로 애플리케이션을 조정할 수 있게 하라. _p.236
• 정적static 설정 
  어떤 형태를 사용하든 여러분의 애플리케이션에서는 설정을 자료 구조 형 태로 불러온다. 보통 처음 애플리케이션을 시작할 때 읽어올 것이다. 흔히 이 자료 구조를 전역에서 접근할 수 있도록 하는데, 코드의 어느 부분에서든 설정 정보에 쉽게 접근할 수 있도록 하기 위해서일 것이다.
  우리는 그렇게 하지 않기를 추천한다. 대신 설정 정보를 (얇은) API 뒤로 숨겨라. 그러면 설정을 표현하는 세부 사항으로부터 여러분의 코드를 떼어 놓을 수 있다. _p.237
• 서비스형 설정Configuration-As-A-Service

    · 여러 애플리케이션이 설정 정보를 공유할 수 있다. 인증과 접근 제어를 붙 여서 애플리케이션마다 보이는 정보가 다르게 만들 수도 있다.

    · 여러 인스턴스에 걸쳐서 전체 설정을 한번에 바꿀 수 있다. 

    · 설정 데이터를 전용 UI로 관리할 수 있다.

    · 설정 데이터를 동적으로 계속 바꿀 수 있다. _p.238

 

 

🤔 오늘 읽은 소감은?

 

    유연한 프로그래밍을 하기위해 실질적으로 어떻게 나아가야 하는 방향성을 보여주는 챕터였다. 우리는 불확정적이고 급변하는 시대에 살고 있기 때문에 우리의 작업물들이 취한 형태는 쉽게 교체하기 편한 코드 ETC 가 강조되는 것이다. 그러기 위해서 코드 간 결합도를 최대한 낮추는 방법들을 소개한다. 객체 지향 프로그래밍에서 결합도를 높이는 이슈들, 관점들에 대해 말하고 있기에 이해를 위해서 어느정도 해당 도메인 지식이 필요한 편이다. 

 

    전반적으로 확 이해하기는 어려운 챕터였다. 그 만큼 많은 내용들이 있기도 하고 저자들의 오랜 경험을 통해서 나름 찾은 노하우, 지식들을 소개하는데 한번에 착 알아 먹기엔 내 수준이 그 만큼은 못되는 걸 것이다. 키워드 별로 여기저기 서치도 해봐야겠고, 일단 최소 3회차 이상은 반복해서 살펴봐야할 것 같다. 그래도 흥미로운 부분들이 많아 읽는데 이해했을때 성취감도 높을거라 예상한다.

 

 

😅 궁금한 내용이 있거나, 잘 이해되지 않는 내용

 

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