Please enable JavaScript.

Coggle requires JavaScript to display documents.

Pragmatic programmer notes, Programming patterns, Refactoring - Coggle…

- - - - Serious investors invest regularly—as a habit.
        
        Learn at least one new language every year
        
        Read a technical book each month
        
        Read nontechnical books, too
        
        Take classes
        
        Participate in local user groups and meetups
        
        Experiment with different environments
        
        Stay current (in rhythm of changes)
      - Diversification is the key to long-term success.
      - Smart investors balance their portfolios between conservative and
      - high-risk, high-reward investments.
      - Investors try to buy low and sell high for maximum return.
      - Portfolios should be reviewed and rebalanced periodically.
- - - - (talking about faults in others' code and not ours
    - - If it took a long time to fix this bug, ask yourself why. Is there
        anything you can do to make fixing this bug easier the next time around?
      - describe the error flow outloud
  - - - Preconditions
        
        what should caller ensure about F inputs?
      - Postconditions
        
        What the F promises to return
      - Invariants
        
        what condition holds before and after the F execution?
        
        semantic invariants
        
        invariants that are derived from the business problem
        E: user transaction never duplicates
    - - explicit failure if preconditions not met (Elixit, Clojure, etc)
      - assertions
        
        To ensure preconditions is the job of client!
    - - when agents negotiate contract in runtime
        E: I have this and if you will have that we can proceed
      - automate only when the picture is clear to yourself!
  - - - only supervisor knows how to handle smth that was 'impossible"
  - - - a directory should exist
      - a counter should 'always' be >0
      - a+1 should never be >= a
  - - - avoid sharing resouce balancing between different units! (choose one abstraction level above instead)
  - - - this implies making code REPLEACABLE & ORTHOGONAL
  - - - many people involved in resolving a problem
      - many changes are required if just one component changes
      - lots of interdependencies and 'knowledge' about how other modules should work for this to continue working
        
        this is where incapsulation becomes extremely important
    - - rather than asking an obj for particular fields / methods to implement your functionality - tell what to do with minimum extra calls
  - - - declares behavior of a C
    - - rather than inheriting 20 methods and using 2, delegate 2 to some service and avoid inheritance
    - - implements behavior to be reused by a C
  - - - when 'tock' must come after 'tick'
    - - Activity diagram - identify what can run in parallel and what should completes before smth else
  - - - Actor - an independent process with private state that has a mailbox to read. If any msg - processing: process data, call other actors, etc. Otherwise - sleep
      - process - actual 'virtual processor' that OS uses to parallelize things
    - - communication is one way - to the mailbox of some A
      - state is inaccessible from outer scope
      - no external concurrency manager
  - - - agents don't know anything about others
      - A don't know how events get on the blackboard
  - - - but you need to be skilled at testing nontheless
  - - - Version Control
        
        a must-have for any project
        
        helps go from dev to prod, etc
        
        Regression Testing
        
        test deliberately, the earlier you find bugs - the better
        
        Full Automation
        
        automate routines / deployment, anything you can that takes your time
    - - Netflix’s Chaos Monkey
        
        introduce bugs on-purpose to test system's resilience
- - - - есть три существа: обезьяна, жираф и лев. Выдается банан, который проходит по цепочке. Кто ест банан - съест, кто нет - передает следующему в цепочке
  - - - клиент общается с интерфейсом Команда, параметризую действия других классов разными конкретными К
    - - пример: сохранить состояние списка транзакций. Тут - команда сохранитьСписок
    - - нужна история изменения (каждая К имеет undo saveBackup (ну или общий интерфейс К имеет эти М))
      - много классов делают одно и то же, общаясь напрямую с бизнес-логикой
      - нужно учесть некую особенность проводимой операции
  - - - (если простого цикла недостаточно)
    - - Три варианта посетить Рим: самостоятельно, купить карту, купить екскурсию. Турист выбирает что ему надо сам
  - - - 4 разнородных объекта передают свои данные через посредник с методом doStuff(sender), где, используя if-else определяется логика обработки sender==ComponentA, sender==ComponentB, etc
  - - - для создания копий состояния объектов
    - - создается класс Хранитель и, отдельно, класс который взаимодействует с целевым К и с Х (для сохранения снимков)
        
        клиент знает про последний класс и делает backup / undo по необходимости
      - снимки хранятся в памяти (может стоить дорого!)
      - Х имеет доступ ко всем (и приватным тоже) полям целевого класса
      - Целевой класс имеет методы backup / restore тогда, когда Х не может быть вложенным в него (нет мех-ма вложенности, как в PHP, Python, etc)
  - - - основной класс знает о методе "оповестить" наблюдателя
        
        наблюдатель (общаясь с общим интерфейсом подписчиков) рассылает необходимый контекст
      - наблюдатель имеет список всех подписчиков (включая особенности их подписок. Н знает кого оповестить на вызове notify у основного класса
    - - позволить компонентам реагировать на изменения в других К
  - - - много состояний и поведение сильно отличается
      - большое дублирование кода в условных операторах
      - можно обобщить поведение К в конечный автомат
    - - И состояние, классы-состояния с целевым объектом в их конструкторе!!
      - ЦО (целевой объект) меняет свое состояние и делегирует выполнение соответствующих методов состоянию, а не выполняет их сам
  - - - клиент знает про контекст, который знает про интерфейс "стратегия" и устанавливает нужную конкретную С во время выполнения программы
        
        конкретные С наследуют общий интерфейс С, переопределяя метод "выполнить"
  - - - парсер файлов для разных типов: пдф, док, ...
    - - сложно поддерживать ввиду привязки к алгоритму и реализации по-умолчанию, которая должна подходить всем наследникам общего алгоритма
  - - - для проблемы раннего связывания, возникающего в компилируемых ЯП
        
        если бы Посетитель имел перегруженные методы для работы с каждым К, компилятор выбирал бы только метод, который принимает И, не принимая во внимания других К
      - раннее / статическое связывание
        
        Раннее, потому что оно происходит ещё на этапе компиляции программы.
        
        Статическое, потому что его уже не изменить во время выполнения.
      - позднее / динамическое связывание
        
        динамическая проверка типа параметров М
        
        Поздним, потому что мы связываем объект и реализацию уже после компиляции.
        
        Динамическим, потому что мы делаем это при каждом прохождении через этот участок.
    - - посетитель
        
        знает о всех К и умеет работать с каждым. Сам метод работы должен вызывать из К из-за двойной диспетчирезации
      - классы, нследующие И
        
        определяют метод accept(visitor), который говорит visitor какой метод-обработчик выполнить (для обработки этого К)
- - - - П: два сервиса, один работает с JSON, другой - с XML
        Решение: адаптер, который наследует класс А и манипулирует объектом класса Б
    - - позволяет минимизировать знание клиента о внутренней структуре классов
  - - - расширение классов в двух независимых плоскостях
        П: функциональность, цвет
      - разбиение монолита на части
        П: есть интерфейс для работы с разными БД, его реализации, и абстракция для клиента, которую он исп. для управления БД
        
        Прим: абстракция может иметь наследников - "улучшенные абстракции"
      - когда нужно иметь возм. заменить реализацию во время выполнения П
  - - - когда Кл должен трактовать объекты разной сложности одинаково
      - когда есть древовидная структура классов (общий корень - И)
  - - - есть интерфейс А, который наследуют А1 и интерфейс-декоратор Д
        
        Декораторы Д1 и Д2 добавляют соответствующий функционал
        
        итого: обернув А1 в декоратор Д1, клиент получает расширенный функционал А1 с ТЕМ ЖЕ интерфейсом
      - Конструктор Д принимает на вход объект А1, который он вызывает согласно интерфейсу А, добавляя свои функции
        
        Д ВСЕГДА вызывает соответствующий метод компонента из конструктора
    - - интерфейс Данные, класс Файловые данные, декоратор ДатаДекоратор
        
        EncryptionDecorator, CompressionDecorator inherit DataDecorator
  - - - создать псевдо-класс (с тяжеловесными параметрами) и фабрику, которая надстраивает внешние параметры над хранимыми экземплярами псевдо-класса
        
        альтернатива - передавать внешние параметры прямо в метод легковеса, который в них нуждается
  - - - например
        
        можно логировать вызовы сервиса
        
        кешировать данные
        
        проверять аутентификацию
    - - клиент работает с интерфейсом, не зная, что это на самом деле заместитель
- - - - Нарушает принцип единственной ответственности класса.
        
        Маскирует плохой дизайн.
        
        Проблемы мультипоточности.
        
        Требует постоянного создания Mock-объектов при юнит-тестировании.
  - - - то объект, который знает, какие шаги строителя нужно вызвать, чтобы получить несколько самых популярных конфигураций автомобилей.
    - - Клиент будет привязан к конкретным классам строителей, так как в интерфейсе директора может не быть метода получения результата
  - - - Клиент знает только про метод clone(), а не весь класс
        Нужно меньше подклассов, которые отличаются лишь наличием доп. полей
      - Есть возможность создать регистр прототипов, где все прототипы предварительно созданы и доступны по имени
- - - - Extend other class with this
      - remove class if its a subcls of almost identical parent
  - - - simplify / divide the method
    - - When explaining why something is being implemented in a particular way.
      - When explaining complex algorithms (when all other methods for simplifying the algorithm have been tried and come up short).
- - - - make chunks of code in one context independent
    - - inline temp
        
        when variable just adds noise
      - when expression is hard to parse
    - - M are usually more understandable than simply 'clever' V naming
    - - case: one temp V is modified multiple times within a M
      - create meaningfully sound Vs for each case
    - - why? if this M is so big that it pollutes the initial C, create a new C with necessary params in constructor
      - make long M refactoring easier
  - - - when field or M is accessed too eagerly by class B than A - move it to B
    - - when C2 is called from C1, and C1 is merely a proxy for doing such calls without its own functionality - make C2 a field of C2 and force client to use C2 directly
        
        helps when adding new methods to C2s
        
        complexity overplays benefits from delegation
    - - honor the single-responsibility principle for C
    - - when C is doing too few currently / in the future, remove it from the hierarchy
    - - create a wrapper / subclass that will have the M you need for the C
    - - deduplicate func used in several places by adding a utility class and delegating logic to it
  - - - evolving, field in a C has its own data and behavior
        
        make a class for this field and move related stuff there, leaving only reference to it in the current C
    - - allows to customize get / set behaviour
      - is more flexible than direct access
      - allows to override get / set behavior in subclasses
    - - pattern for reference: frequently accessed, passed btw funcs code
    - - mind that privates take more CPU cycles to fetch
    - - class
      - subclass
      - state ./ strategy
      - why
        
        abstract operation on class attribute which semantically denotes a type, but is a string / int currently
    - - why
        
        when subclasses are dead weight (for example, some methods return constant values), extract this to a parent's attribute and create the corresponding method to fetch it
  - - - consider exceptions to make errors typed
  - - - error codes come from procedural programming, Modern lang support exception handling
    - - when exception could be replaced by a simpler construct - do it
  - - - when inheritance is done purely based on code reuse, consider composition instead
      - inheritance = class extension, not simple code reuse
      - create a private field - previosly parent object - and delegate execution to it
- - - - long chains of method calls from the client