Огляд книги «Патерни проектування на платформі .NET»

Як відомо, нещодавно була опублікована книга за паттернам проектування за авторством Сергія Теплякова.

Щоб підтримати мною шановного нашого розробника (сам Сергій, незважаючи на переїзд за кордон, все ще вважає себе нашим — за пруфом йдіть до нього в блозі), не пошкодував грошей і відразу ж купив електронну версію. До цього я читав банду чотирьох і Design Patterns Head First, тому, в принципі, є з чим порівняти.
Книга займає трохи більше 300 сторінок, що цілком можна осилити за тиждень неквапливого читання. Книга розбита на 4 частини:

  1. Патерни поведінки
  2. Породжують патерни
  3. Структурні патерни
  4. Принципи проектування


Розбиття патернів на такі групи вже давно усталилася і прижилося. На відміну від банди чотирьох у книзі Сергія є глава, присвячена SOLID-принципам проектування (власне, в книзі банди чотирьох цих принципів в тому вигляді, в якому ми з ними знайомі і бути не могло, оскільки були сформульовані пізніше). У книзі банди чотирьох є практична глава, яка ілюструє патерни на прикладі розробки текстового редактора. На протязі всього тексту в якості прикладів Сергієм використовуються проблеми, що виникають при розробці програми по обробці логів (як я зрозумів, тема близька до того, чим зараз займається Сергій в компанії Microsoft). Окремої практичної голови, як у випадку з бандою чотирьох немає. В принципі, автору непогано вдається розбирати патерни на такому прикладі, однак, хотілося б зауважити, що все дається дуже легко, тобто, по ходу розповіді особливих проблем не виникає — все лягає як по маслу. Швидше за все, так і було задумано при написанні, але мені здалося не дуже приємним, що ніде немає челлендж (вибачте, за варваризм). Приклад з текстовим редактором виглядає цікавіше, на мій погляд. До недоліків книги я це зауваження віднести безпосередньо, звичайно ж, не можу.

Ця книга — той рідкісний випадок, коли я просто взяв книгу і прочитав її від початку і до кінця. І повинен вам сказати, що книга читається дуже навіть легко. Звичайно, розробник, тільки почав своє ознайомлення з патернами, навряд чи зможе так безтурботно прочитати всю книгу, але, думаю, що для новачка все одно важко уявити книгу більш просту для розуміння, ніж ця. Більш глибокому розумінню патернів сприяє стиль і форма викладу, обрана автором: книга багато в чому є відображенням власного досвіду, а не тупий компіляцією чужих думок, і це дуже імпонує. Приклади, незважаючи на те, що вибраний тип додатка мені не дуже сподобався, все одно гарні і зі своїм завданням справляються. Для новачків може виявитися цікавим порівняти свій досвід з авторським. Найчастіше я знаходив підтвердження своїх власних думок, які мені не з ким було обговорити. Тому, особисто у мене, в процесі читання книги постійно відбувався внутрішній діалог з автором.

Що стосується цільової аудиторії книги, то хотілося б зауважити, що хоч .NET і є безліч власних булочок, але таких булочок, які надавали б величезний вплив на форму патернів зовсім мало. З розгону можу згадати лише те, що в .NET можна зробити явну реалізацію інтерфейсу і спростити деякі патерни, використовуючи делегати. Ну і так — немає множинного спадкоємства, що, наприклад, Боб Мартін вважає, по суті, косяком команди .NET, оскільки «deadly diamond of death» не настільки страшний, як його малюють, зате множинне спадкування у деяких випадках може виявитися дуже корисним (хоча, трапляється це не сказати, щоб часто). Оскільки особливостей платформи .NET не так багато, то книгу можуть читати всі хто цікавляться патернами, в незалежності від языкаисповедания.

Автор наводить класичні діаграми патернів, які густо використовують спадкування, але дуже часто дає спрощені варіанти, оскільки в класичному вигляді патерни використовуються досить рідко. У цілому, автор не забуває вказати, що не слід використовувати наосліп патерни і вчить включати мозок, танцюючи від завдання і вимог. Зазначу також, важливим є те, що використання патернів розглядається в зв'язці з написанням unit-тестів.

В темі, де Сергій анонсував те, що він пише книгу, знайшлися люди, які не забули сказати, що «патерни — фігня, ось обчитаются люди, а потім роблять фабрики фабрик фабрик фабрик з мегафасадами і ще 100500 патернів там, де не треба, навіщо всі ці книги паттернам, всі ці паттерни і так зрозумілі». На мою скромну думку, велика частина таких людей пише нечитабельний underengineered говнокод, який потім переписують по тисячі разів. Це раз. По-друге, так, бездумне застосування патернів — погано і в хорошій книзі про це теж написано. Програмування це інженерія, а в інженерії немає срібних куль і універсальних відповідей на всі питання. Тому хороші програмісти завжди зважують, що вони ставлять на кон і що готові принести на вівтар складності в цілях вирішення завдання. На жаль, не буває книг, які навчають такого мистецтва (якщо хто бачив такі — поділіться), бо досягти розуміння того, як дотримати баланс між складністю, простотою і потужністю рішень можна тільки з допомогою багатьох років наполегливих тренувань на реальних завданнях.
Мені сподобалася в книзі думка про те, що слідування (навіть правильне і гарне слідування) всім принципам не дає гарантії досягнення шикарного дизайну програми. Все залежить від завдання, від того як ООП ляже на таку задачу, в кінці-то кінців.

У книзі розглянуті наступні класичні патерни: «bridge», «flyweight», «chain of responsibility», «memento», «prototype».
Патерн «prototype» досить тупий і реалізується через жахливий ICloneable (не дає розуміння того, що це копія — глибока або поверхнева), хоча, реалізацію, звичайно, можна поліпшити. Може бути, тому цей патерн був виключений з книги. Інші патерни досить цікаві і я не знаю, чому вони були виключені з розгляду. У книзі також не розглядаються всякі «складові» патерни, типу MVC, MVP, MVVM. Вірніше, вони зачіпаються мимохіть, але автор в них не поглиблюється, і, здається, це правильно, оскільки кожному з них можна присвятити окрему книгу.

Одним з небагатьох моментів, де я не зовсім згоден з автором з'явився момент щодо викиду недекларованих винятків спадкоємцями, якщо ці винятки не прописані в контракті базового класу, або не зазначено в XML коментарях у відповідному розділі. Вказувати можливі винятки, декларувати їх у контрактах (я не користувався контрактами, але по книзі зрозумів, що задекларувати можливі типи винятків можна) — не є поганою практикою, але це особливо нічого не дає, крім помилкової впевненості в тому, що викликається коду будуть летіти тільки задекларовані виключення. Скільки ви методів бачили в BCL, які лізуть, скажімо, у файлову систему і декларують всі типи можливих винятків? Правильно, таких методів немає. Від концепції перевіряються винятків розробники .NET відмовилися спочатку. Система обробки помилок через виключення раніше є великим і жирним гемороєм для тих, хто хоче розробляти стабільні додатки. Для правильної обробки помилок через виключення потрібно багато: грамотна побудова архітектури, грамотне виділення типів виключень, грамотне написання тестів, контрактів та інше. Якщо хоча б в одній із цих сфер у команди розробників є проблеми, то додаток буде падати з завидною регулярністю, причому найчастіше від усяких «нешкідливих винятків», коли роботу можна було б і продовжити.

На закінчення хотілося б сказати спасибі Сергію за чудову книгу, пишіть ще! За десятибальною шкалою я б оцінив книгу в 8-8.5.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.