Python і High Load Lohika morning

1. закінчив курс learnpythonthehardway.org і прочитав learnxinyminutes.com по тому ж python. Відчув себе джуном-початківцем. Синтаксис мови тепер не викликає відторгнення, є бажання щось написати.
   Lifehack про друкування коду прикладів - найкраща порада для освоєння нової мови програмування.
2. Сходив на morning.lohika.com по High Load, який провів гість з Києва Дмитро Думанський. Цікаво і добра вправа для голови. На планшет або телефон часу не було варто витрачати.
   Відчував всю доповідь і сесію питань і відповідей - скільки ж ще мені вчити і отримувати досвід.
   Але потім сходив на ленту автора на Хабрі, де були співпадіння з презентацією (а я читав лише статтю автора на доу, глибше не пішов, менше цікаво на доповіді не було), почитав коментарі.
   Звичайно, хабровські троллі, які не ставлять у приклад власні проекти, а лише відмовляють авторові у цінності викладення матеріалів, порадували.
   Але легше стало :)

Краще ніж вчора

В рамках задуманого місячника "Сьогодні краще ніж вчора" почав із прояснення для себе що ж таке SOLID - принцип, про який мене досить часто питають на співбесідах.

Дуже вчасно під руку потрапили сторінки київського программіста-дотнетчика. Я підписаний на його блог, колись намагався погортати його, але застряг. Пише розумні речі, які в голову одразу не заходять. Статті він писав декілька місяців, але я терпляче чекав коли він допише всю серію по абревіатурі - щоб у голові все одразу вклалося.
І ось нещодавно він, здається, дописав.

Особливим успіхом похвалитися не можу, але сподіваюся, що наступного разу це питання мені не буде здаватися таким формальним, і я зможу про SOLID поговорити, а не просто відбарабанити завчені визначення. Я на всі 100% автора не зрозумів. Можливо, пізніше перечитаю і відчую просвітлення. Але зрушення були.

Якщо ви не я, то раджу читати прямо автора - в нього більше, розгорнуто, краще. Тут пишу більше для себе, конспектую виконання намагань стати сьогодні краще, ніж вчора.

• S – Single Responsibility Principle
• O – Open-Closed Principle (Часть 2. ФП vs ООП)
• L – Liskov Substitution Principle (LSP. Часть 2. О наследовании)
• I – Interface Segregation Principle
• D – Dependency Inversion Principle (Критический взгляд на DIP)
• О принципах проектирования

Даний принцип стосується проектування і архітектури.

Отже, що як я тепер буду розшифровувати дану абревіатуру:

• S - Single Responsibility Priciple
  Клас повинен мати лише одну причину для зміни.
  Тобто потрібно так керувати складністю і розділяти відповідальність між класами, щоб наступні зміни в систему були якомога легшими, без тривалих досліджень і переробок. (Саме тому не варто покладати відповідальність на один і той же клас для роботи з базою даних і інтерфейсом користувача) 
• O - Open / Close Principle
  Програмні конструкти повинні бути відкритими для змін і закритими для модифікації.
  Мова йдеться про стабільність (закритість для змін) інтерфейсу взаємодії програмних конструктів і вільність зміни їх реалізації.
  Теж боротьба із складністю внесень в систему архітектурних змін.
• L - Liskov Substitution Principle
  Повинна бути можливість заміни базового класу на його похідний.
  Автор пише про збереження дизайном умов контракту при змінах у системі.
• I - Interface Segragation Principle
  Зменшення зв'язності за рахунок розділення інтерфейсів для конструкту, які можуть використувувати різні клієнти.
• D - Dependency Inversion Principle
  Модулі верхнього рівня не повинні залежати від модулів нижнього рівня, і обоє повинні залежати від абстракцій. Абстракції не повинні залежати від деталей, деталі повинні залежати від абстракцій.
  Заміна композиції агрегацією. Залежності вносяться зовні (через параметри методів чи конструкторів), а не закладені намертво в клас.