Дуже вчасно під руку потрапили сторінки київського программіста-дотнетчика. Я підписаний на його блог, колись намагався погортати його, але застряг. Пише розумні речі, які в голову одразу не заходять. Статті він писав декілька місяців, але я терпляче чекав коли він допише всю серію по абревіатурі - щоб у голові все одразу вклалося.
І ось нещодавно він, здається, дописав.
Особливим успіхом похвалитися не можу, але сподіваюся, що наступного разу це питання мені не буде здаватися таким формальним, і я зможу про 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
Модулі верхнього рівня не повинні залежати від модулів нижнього рівня, і обоє повинні залежати від абстракцій. Абстракції не повинні залежати від деталей, деталі повинні залежати від абстракцій.
Заміна композиції агрегацією. Залежності вносяться зовні (через параметри методів чи конструкторів), а не закладені намертво в клас.
Комментариев нет:
Отправить комментарий