Мы постоянно имеем дело с MVC в процесс разработки сайтов на фрэймворках. И каждый раз, начиная новый проект, разработчик надеется сделать его лучше, чем предыдущий, применить в своем новом релизе весь накопленный опыт разработки. Иногда разработчик пытается освоить другие, новые для себя, фрэймворки, которые в наибольшей степени соответствуют по своей модности. И напротив, придерживающиеся более консервативных взглядов, стараются «юзать» свой привычный фрэймворк. Так или иначе, разработчику приходится писать свои библиотеки, модули или внедрять готовые решения. Сразу напрашивается вывод: «нет особого резона гоняться за фрэймворком».
Каждый правильный разработчик в глубине души надеется, что его проект не умрет и не запылится в рейд-массиве какого-либо Облака на «безымянном» хостинге. Но, как правило, сам разработчик не хочет в будущем заниматься поддержкой сданного проекта, особенно когда его потенциал теперь устремлен к разработке нового интересного проекта. Но есть и другая категория разработчиков, основной задачей которых является поддержка и развитие проекта после ввода его в эксплуатацию, и не всегда эти специалисты принимали непосредственное участие в процессе разработки до выхода проекта в эксплуатацию. Поэтому продолжим последний вывод: "..., достаточно остановить свой выбор на популярном, хорошо документированном фрэймворке с продвинутым комьюнити разработчиков либо с «богатым папой», типа Zend".
Не стоит, однако, забывать о необходимости грамотного применения различных библиотек и технологий. Но самое главное — это выбрать правильный подход к разработке. Сейчас, вероятно, любой разработчик понимает всю необходимость применения «Образов разработки» в современных web-проектах. Возможно, кто-то не согласится, и станет утверждать, что использование «патернов проектирования» и даже ООП слишком избыточно, с точки зрения производительности, не оптимально используются ресурсы процессора и памяти, и, что это слишком «круто» для web, особенно если код обрабатывает потом интерпретатор, и, что усложняется процесс отладки кода. В какой-то мере все это так. Но, как показывает практика, проблема нехватки процессорных ресурсов стоит, как правило, на последнем месте, если речь идет о крупных web-проектах с огромной посещаемостью, таких как, например, Facebook. В условиях, как это модно говорить, «High Load», основные проблемы сводятся, банально, к количеству оборотов шпиндельного двигателя жесткого диска в секунду, благодаря «шторму» запросов к базе данных, непрерывно поступающих от пользователей «мировой паутины». Высоконагруженные проекты, как известно, требуют горизонтального масштабирования базы данных проекта на множество кластеров в одном или нескольких датацентрах. А ресурсы оперативной памяти почти полностью расходуются в целях кэширования данных. Вывод такой: «не стоит экономить на гибкости разработки web-проекта и его дальнейшего сопровождения, которую гарантирует использование Патернов проектирования».
Чего не советую использовать при построении объектной модели web-проекта: избегайте множественного наследования — это далеко не круто и совсем не гибко.
Недостатки множественного наследования:
Каждый правильный разработчик в глубине души надеется, что его проект не умрет и не запылится в рейд-массиве какого-либо Облака на «безымянном» хостинге. Но, как правило, сам разработчик не хочет в будущем заниматься поддержкой сданного проекта, особенно когда его потенциал теперь устремлен к разработке нового интересного проекта. Но есть и другая категория разработчиков, основной задачей которых является поддержка и развитие проекта после ввода его в эксплуатацию, и не всегда эти специалисты принимали непосредственное участие в процессе разработки до выхода проекта в эксплуатацию. Поэтому продолжим последний вывод: "..., достаточно остановить свой выбор на популярном, хорошо документированном фрэймворке с продвинутым комьюнити разработчиков либо с «богатым папой», типа Zend".
Не стоит, однако, забывать о необходимости грамотного применения различных библиотек и технологий. Но самое главное — это выбрать правильный подход к разработке. Сейчас, вероятно, любой разработчик понимает всю необходимость применения «Образов разработки» в современных web-проектах. Возможно, кто-то не согласится, и станет утверждать, что использование «патернов проектирования» и даже ООП слишком избыточно, с точки зрения производительности, не оптимально используются ресурсы процессора и памяти, и, что это слишком «круто» для web, особенно если код обрабатывает потом интерпретатор, и, что усложняется процесс отладки кода. В какой-то мере все это так. Но, как показывает практика, проблема нехватки процессорных ресурсов стоит, как правило, на последнем месте, если речь идет о крупных web-проектах с огромной посещаемостью, таких как, например, Facebook. В условиях, как это модно говорить, «High Load», основные проблемы сводятся, банально, к количеству оборотов шпиндельного двигателя жесткого диска в секунду, благодаря «шторму» запросов к базе данных, непрерывно поступающих от пользователей «мировой паутины». Высоконагруженные проекты, как известно, требуют горизонтального масштабирования базы данных проекта на множество кластеров в одном или нескольких датацентрах. А ресурсы оперативной памяти почти полностью расходуются в целях кэширования данных. Вывод такой: «не стоит экономить на гибкости разработки web-проекта и его дальнейшего сопровождения, которую гарантирует использование Патернов проектирования».
Чего не советую использовать при построении объектной модели web-проекта: избегайте множественного наследования — это далеко не круто и совсем не гибко.
Недостатки множественного наследования:
- нет 100% гарантии получения верного результата при пересечении элементов (свойств, методов) структур данных разных типов (классов), об этих классах всегда приходится помнить разработчику;
- злоупотребляя наследованием вообще (не только множественным) мы получаем громоздкий класс, объединяющий множество методов и свойств собственных предков, некоторые методы и свойства которых уже возможно даже не нужны в классе-потомке; объекты таких классов могут оказаться весьма избыточными;
- теряется гибкость сопровождения класса, когда понадобится изменить один из классов-предков, возникнет необходимость изменения все или некоторых потомков;
- если появится необходимость создания множества схожих по функционалу объектов, но при этом требующих разного набора из всех классов-предков, или же последовательность наследования классов-предков таких объектов будет разной, то в таком случае понадобится для каждого такого объекта создавать свой класс, который будет отличаться от других всего лишь последовательностью наследования предков или их составом.