Об "явлення розробника

Ми постійно маємо справу з MVC у процес розробки сайтів на фреймворках. І щоразу, починаючи новий проект, розробник сподівається зробити його кращим, ніж попередній, застосувати у своєму новому релізі весь накопичений досвід розробки. Іноді розробник намагається освоїти інші, нові для себе, фреймворки, які найбільшою мірою відповідають за своєю модністю. І навпаки, притримуються більш консервативних поглядів, намагаються «юзати» свій звичний фреймворк. Так чи інакше, розробнику доводиться писати свої бібліотеки, модулі або впроваджувати готові рішення. Відразу напрошується висновок: «немає особливого резону ганятися за фреймворком».

Кожен правильний розробник в глибині душі сподівається, що його проект не помре і не запилиться в рейд-масиві якогось Облака на «безіменному» хостингу. Але, як правило, сам розробник не хоче в майбутньому займатися підтримкою зданого проекту, особливо коли його потенціал тепер спрямований до розробки нового цікавого проекту. Але є й інша категорія розробників, основним завданням яких є підтримка і розвиток проекту після введення його в експлуатацію, і не завжди ці фахівці брали безпосередню участь у процесі розробки до виходу проекту в експлуатацію. Тому продовжимо останній висновок: «»..., досить зупинити свій вибір на популярному, добре документованому фреймворку з просунутим ком'юніті розробників або з «багатим папою», типу Zend «».

Не варто, однак, забувати про необхідність грамотного застосування різних бібліотек і технологій. Але найголовніше - це вибрати правильний підхід до розробки. Зараз, ймовірно, будь-який розробник розуміє всю необхідність застосування «Образів розробки» в сучасних web-проектах. Можливо, хтось не погодиться, і стане стверджувати, що використання «патернів проектування» і навіть ОВП занадто надлишково, з точки зору продуктивності, не оптимально використовуються ресурси процесора і пам'яті, і, що це занадто «круто» для web, особливо якщо код обробляє потім інтерпретатор, і, що ускладнюється процес налагодження коду. Якоюсь мірою все це так. Але, як показує практика, проблема нестачі процесорних ресурсів стоїть, як правило, на останньому місці, якщо мова йде про великі web-проекти з величезною відвідуваністю, такі як, наприклад, Facebook. В умовах, як це модно говорити, «High Load», основні проблеми зводяться, банально, до кількості оборотів шпиндельного двигуна жорсткого диска в секунду, завдяки «шторму» запитів до бази даних, що безперервно надходять від користувачів «світової павутини». Високозавантажені проекти, як відомо, потребують горизонтального масштабування бази даних проекту на безліч кластерів в одному або декількох датацентрах. А ресурси оперативної пам'яті майже повністю витрачаються з метою кешування даних. Висновок такий: «не варто економити на гнучкості розробки web-проекту і його подальшого супроводу, яку гарантує використання Патернів проектування».

Чого не раджу використовувати при побудові об'єктної моделі web-проекту: уникайте множинної спадкування - це далеко не круто і зовсім не гнучко.

Недоліки множини спадкування:

• немає 100% гарантії отримання правильного результату при перетині елементів (властивостей, методів) структур даних різних типів (класів), про ці класи завжди доводиться пам'ятати розробнику;
• зловживаючи спадкуванням взагалі (не тільки множинним) ми отримуємо громіздкий клас, що об'єднує безліч методів і властивостей власних предків, деякі методи і властивості яких вже можливо навіть не потрібні в класі-нащадку; об'єкти таких класів можуть виявитися досить надлишковими;
• втрачається гнучкість супроводу класу, коли знадобиться змінити один з класів-предків, виникне необхідність зміни всі або деяких нащадків;
• якщо з'явиться необхідність створення безлічі схожих за функціоналом об'єктів, але при цьому потребують різного набору з усіх класів-предків, або ж послідовність успадкування класів-предків таких об'єктів буде різною, то в такому випадку знадобиться для кожного такого об'єкта створювати свій клас, який буде відрізнятися від інших всього лише послідовністю спадкування предків або їх складом.

Уявіть: Якщо кожен клас відповідатиме за виведення однієї конкретної літери алфавіту, то, в умовах спадкування, для побудови кожного різного словосполучення знадобиться написати окремий клас, який успадкує всі класи літер алфавіту у своєму складі. В результаті море класів, а це дуже не гнучко. Якщо спадкування не гнучке, то чим його замінити? Відповідь: спадкуванням. Але спадкуванням не класів, а об'єктів різних класів, про це свідчить основний закон об'єктно-орієнтованого проектування. «Різних» - не зовсім різних, всі ці об'єкти будуть реалізовувати один інтерфейс. Такий підхід реалізується патерном «Composite» і покриває всі недоліки спадкування класів, при цьому додаючи можливість динамічно додавати/видаляти компоненти спадкування, переміщати їх з «вузла до вузла», динамічно змінювати їх поведінку і додавати нові властивості. Єдиним недоліком «Композиції» є складність у налагодженні. Рекомендую застосовувати патерн «Composite», при побудові «View», якщо фреймворк не дає такої можливості, то не важко реалізувати свій «Composite View».