Как стать автором
Обновить

Откровение разработчика

Время на прочтение 4 мин
Количество просмотров 643
Мы постоянно имеем дело с MVC в процесс разработки сайтов на фрэймворках. И каждый раз, начиная новый проект, разработчик надеется сделать его лучше, чем предыдущий, применить в своем новом релизе весь накопленный опыт разработки. Иногда разработчик пытается освоить другие, новые для себя, фрэймворки, которые в наибольшей степени соответствуют по своей модности. И напротив, придерживающиеся более консервативных взглядов, стараются «юзать» свой привычный фрэймворк. Так или иначе, разработчику приходится писать свои библиотеки, модули или внедрять готовые решения. Сразу напрашивается вывод: «нет особого резона гоняться за фрэймворком».

Каждый правильный разработчик в глубине души надеется, что его проект не умрет и не запылится в рейд-массиве какого-либо Облака на «безымянном» хостинге. Но, как правило, сам разработчик не хочет в будущем заниматься поддержкой сданного проекта, особенно когда его потенциал теперь устремлен к разработке нового интересного проекта. Но есть и другая категория разработчиков, основной задачей которых является поддержка и развитие проекта после ввода его в эксплуатацию, и не всегда эти специалисты принимали непосредственное участие в процессе разработки до выхода проекта в эксплуатацию. Поэтому продолжим последний вывод: "..., достаточно остановить свой выбор на популярном, хорошо документированном фрэймворке с продвинутым комьюнити разработчиков либо с «богатым папой», типа Zend".

Не стоит, однако, забывать о необходимости грамотного применения различных библиотек и технологий. Но самое главное — это выбрать правильный подход к разработке. Сейчас, вероятно, любой разработчик понимает всю необходимость применения «Образов разработки» в современных web-проектах. Возможно, кто-то не согласится, и станет утверждать, что использование «патернов проектирования» и даже ООП слишком избыточно, с точки зрения производительности, не оптимально используются ресурсы процессора и памяти, и, что это слишком «круто» для web, особенно если код обрабатывает потом интерпретатор, и, что усложняется процесс отладки кода. В какой-то мере все это так. Но, как показывает практика, проблема нехватки процессорных ресурсов стоит, как правило, на последнем месте, если речь идет о крупных web-проектах с огромной посещаемостью, таких как, например, Facebook. В условиях, как это модно говорить, «High Load», основные проблемы сводятся, банально, к количеству оборотов шпиндельного двигателя жесткого диска в секунду, благодаря «шторму» запросов к базе данных, непрерывно поступающих от пользователей «мировой паутины». Высоконагруженные проекты, как известно, требуют горизонтального масштабирования базы данных проекта на множество кластеров в одном или нескольких датацентрах. А ресурсы оперативной памяти почти полностью расходуются в целях кэширования данных. Вывод такой: «не стоит экономить на гибкости разработки web-проекта и его дальнейшего сопровождения, которую гарантирует использование Патернов проектирования».

Чего не советую использовать при построении объектной модели web-проекта: избегайте множественного наследования — это далеко не круто и совсем не гибко.
Недостатки множественного наследования:
  • нет 100% гарантии получения верного результата при пересечении элементов (свойств, методов) структур данных разных типов (классов), об этих классах всегда приходится помнить разработчику;
  • злоупотребляя наследованием вообще (не только множественным) мы получаем громоздкий класс, объединяющий множество методов и свойств собственных предков, некоторые методы и свойства которых уже возможно даже не нужны в классе-потомке; объекты таких классов могут оказаться весьма избыточными;
  • теряется гибкость сопровождения класса, когда понадобится изменить один из классов-предков, возникнет необходимость изменения все или некоторых потомков;
  • если появится необходимость создания множества схожих по функционалу объектов, но при этом требующих разного набора из всех классов-предков, или же последовательность наследования классов-предков таких объектов будет разной, то в таком случае понадобится для каждого такого объекта создавать свой класс, который будет отличаться от других всего лишь последовательностью наследования предков или их составом.
Представьте: Если каждый класс будет отвечать за вывод одной конкретной буквы алфавита, то, в условиях наследования, для построения каждого разного словосочетания понадобится написать отдельный класс, который унаследует все класса букв алфавита в своем составе. В результате море классов, а это очень не гибко. Если наследование не гибко, то чем его заменить? Ответ: наследованием. Но наследованием не классов, а объектов разных классов, об этом гласит основной закон объектно-ориентированного проектирования. «Разных» — не совсем разных, все эти объекты будут реализовывать один интерфейс. Такой подход реализуется патерном «Composite» и покрывает все недостатки наследования классов, при этом добавляя возможность динамически добавлять/удалять компоненты наследования, перемещать их из «узла в узел», динамически менять их поведение и добавлять новые свойства. Единственным недостатком «Композиции» является сложность в отладке. Рекомендую применять патерн «Composite», при построении «View», если фрэймворк не дает такой возможности, то не трудно реализовать свой «Composite View».
Теги:
Хабы:
-10
Комментарии 12
Комментарии Комментарии 12

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн