зачем нужны паттерны проектирования
Зачем нужны паттерны проектирования или «Что такое MVC?»
Самое главное во всех фреймворках это то, что все они диктуют правила создания приложения. Если ты никогда не использовал никакого фреймворка в своих приложениях, то либо они слишком малы и ты не сталкивался с проблемой нарастающего хаоса в коде, либо просто не пришло твоё время 🙂 И в конце концов приложение созданное по правилам фреймворка однозначно обретёт правильную форму. А разве не этого все мы хотим? Новичок в программировании начав изучение какого-либо фреймворка автоматически начинает правильно мыслить, тем самым перенимая опыт предыдущих поколений и открывая себе более гладкую дорогу вперёд. В любом случае единственная возможность создания больших, расширяемых и модульных приложений это использование фреймворка.
MVC «Модель-представление-поведение» === «Модель-представление-контроллер».
А теперь закрой глаза и представь себе работу своего приложения. Представил?… так вот, попробуй условно разбить этот процесс на три абстрактые логические части:
Собери все методы своего приложения которые занимаются обработкой всех визуальных компонентов, методы которые имеют знания о визуальном элементе, которые занимаются перемещением их по экрану и т.д. Мысленно объедини их в одну часть программы, это и будет (Представление).
Далее. Собери все методы своего приложения которые занимаются логикой приложения, методы которые имеют знания о том, что и как делать. Модель поведения компонентов приложения. Мысленно объедини их в одну часть программы, это и будет (Модель).
Третья, но не менее важная часть, это те методы в которых реализовано само поведение модели. Так называемый «Контроллер». Вообщем это любые методы, которые вызываются к примеру событием проигрыша игры, допустим: function onLoseLevel(e:SomeEvent):void. В данном случае этот метод является поведением модели вашего приложения в случае проигрыша. Как только вы проиграли уровень вызывается конкретный метод, которые реализует поведение приложения в конкретном случае. Так вот, собери все методы, реализующие поведение в одну кучу
это и будет третья логическая часть концепции MVC, (Контроллер).
Для тех кто не до конца понял и не ответил на вопрос для чего нужно это все разбиение: Для того, чтобы уменьшить связываемость кода, т.е. меняя, что-то в проекте изменения не затронут другой части программы. Таким образом наше приложение может быть более гибким и состоять из независимых модулей и приспособлено к рефакторингу.
Реализация концепции MVC на примере приложения HellowWorld
Ок. Разберём что же здесь происходит. Есть Главный класс приложения: HelloWorld.as который ответственный за всё. В нём мы создаём один единственный визуальный компонент типа TextField (текстовое поле), а также экземпляры Model.as, View.as и Controller.as. Теперь как это всё связать?
Для начала передадим визуальный компонент в управление нашему View путём передачи его в конструктор:
artemfedorov.com/?p=64
Теперь наша View знает о компоненте.
Далее, добавим метод во View с помощью которого она сможет влиять на компонент:
здесь всего лишь происходит присвоение текстовому полю компонента нового значения типа String.
Наша Model в этом примере содержит лишь знания о значении строковой переменной и на это бизнес логика ограничивается.
Controller содержит тоже лишь одну команду, которая получает значение из Model и сообщает View что нужно сделать:
Далее заключительный штрих без которого ничего не будет работать это событие. Здесь для примера события я выбрал событие, которое возникает когда происходит добавление на stage и добавил слушатель:
addEventListener(Event.ADDED_TO_STAGE, showTextHandler);
К этому событию я привязал команду реализуя поведение моего приложения:
Основы паттернов проектирования
Введение в паттерны проектирования
Что представляют собой паттерны проектирования? Паттерн представляет определенный способ построения программного кода для решения часто встречающихся проблем проектирования. В данном случае предполагается, что есть некоторый набор общих формализованных проблем, которые довольно часто встречаются, и паттерны предоставляют ряд принципов для решения этих проблем.
Хотя идея паттернов как способ описания решения распространенных проблем в области проектирования появилась довольно давно, но их популярность стала расти во многом благодаря известной работе четырех авторов Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона, Джона Влиссидеса, которая называлась «Design Patterns: Elements of Reusable Object-Oriented Software» (на русском языке известна как «Приемы объектно-ориентированного проектирования. Паттерны проектирования») и которая вышла в свет в 1994 году. А сам коллектив авторов нередко называют «Банда четырёх» или Gang of Four или сокращенно GoF. Данная книга по сути являлась первой масштабной попыткой описать распространенные способы проектирования программ. И со временем применение паттернов стало считаться хорошей практикой программирования.
Что же дает нам применение паттернов? При написании программ мы можем формализовать проблему в виде классов и объектов и связей между ними. И применить один из существующих паттернов для ее решения. В итоге нам не надо ничего придумывать. У нас уже есть готовый шаблон, и нам только надо его применить в конкретной программе.
Причем паттерны, как правило, не зависят от языка программирования. Их принципы применения будут аналогичны и в C#, и в Jave, и в других языках. Хотя в рамках данного руководства мы будем говорить о паттернах в контексте языка C#.
Также мышление паттернами упрощает групповую разработку программ. Зная применяемый паттерн проектирования и его основные принципы другому программисту будет проще понять его реализацию и использовать ее.
В то же время не стоит применять паттерны ради самих паттернов. Хорошая программа предполагает использование паттернов. Однако не всегда паттерны упрощают и улучшают программу. Неоправданное их использование может привести к усложнению программного кода, уменьшению его качества. Паттерн должен быть оправданным и эффективным способом решения проблемы.
Существует множество различных паттернов, которые решают разные проблемы и выполняют различные задачи. Но по своему действию их можно объединить в ряд групп. Рассмотрим некоторые группы паттернов. В основу классификации основных паттернов положена цель или задачи, которые определенный паттерн выполняет.
Порождающие паттерны
Порождающие паттерны — это паттерны, которые абстрагируют процесс инстанцирования или, иными словами, процесс порождения классов и объектов. Среди них выделяются следующие:
Абстрактная фабрика (Abstract Factory)
Фабричный метод (Factory Method)
Цепочка обязанностей (Chain of responsibility)
Шаблонный метод (Template method)
Существуют и другие классификации паттернов в зависимости от того, относится паттерн к классам или объектам.
Паттерны классов описывают отношения между классами посредством наследования. Отношения между классами определяются на стадии компиляции. К таким паттернам относятся:
Фабричный метод (Factory Method)
Шаблонный метод (Template Method)
Паттерны проектирования: твоя настольная статья
Зачем вам паттерны проектирования? Сайт proglib.io опубликовал статью с кратким описанием паттернов и их назначения.
Давайте разбираться, как отличить композицию от агрегации и что лучше: наследование или композиция.
Паттерны проектирования делятся на три группы.
1. Порождающие паттерны
1. Абстрактная фабрика помогает создавать семейства объектов с общими связями или зависимостями без указания их конкретных классов. Фабрики и продукты – основа паттерна. Как раз слово «семейства» отличает шаблон от других порождающих паттернов, где только один тип объекта.
2. Строитель отделяет конструирование сложного объекта от его представления. Представьте приготовление чая с сахаром, чая с молоком и обыкновенного чая. Вы одинаково кипятите воду и насыпаете заварку, а в зависимости от типа добавляете сахар, вливаете молоко или ничего не делаете.
3. Фабричный метод определяет интерфейс для конструирования объекта и даёт свободу дочерним классам выбирать тип класса.
Паттерн делегирует создание экземпляров подклассам. Создадим полосу прокрутки в стиле Mac:
А чтобы это работало на любой платформе, напишем код:
Переменную экземпляра guiFactory инициализируем так:
4. Прототип определяет тип объектов с применением прототипического экземпляра и создаёт новые путём его копирования.
5. Одиночка гарантирует, что у класса будет единственный экземпляр, и предоставляет глобальную точку доступа к нему.
2. Структурные паттерны
1. Адаптер конвертирует интерфейс класса в ожидаемый клиентами интерфейс. Благодаря этому классы работают вместе, несмотря на несовместимость интерфейсов.
2. Мост отделяет абстракцию объекта от его реализации.
3. Компоновщик объединяет объекты в структуры в виде дерева для представления иерархий частей и целого. Поэтому клиенты одинаково работают и с одним объектом, и с композицией объектов.
4. Декоратор добавляет обязанности к объектам динамически. Это гибкая альтернатива дочерним классам для расширения функциональности.
5. Фасад – единственный класс, представляющий целую подсистему.
6. Приспособленец – мелкоструктурный экземпляр для облегчения и оптимизации совместного доступа.
7. Заместитель изображает и представляет другой объект.
3. Поведенческие паттерны
1. Посредник определяет упрощённую связь между классами.
2. Хранитель фиксирует и восстанавливает внутреннее состояние объекта.
3. Интерпретатор – способ добавления языковых элементов в программу.
4. Итератор – последовательный доступ к элементам коллекции.
5. Цепочка обязанностей – способ передачи запросов между цепочкой объектов.
6. Команда упаковывает запрос в объект для параметризации отличающихся клиентов, создания очереди, логирования или поддержки операции отмены.
7. Состояние трансформирует поведение объекта, когда он меняет своё состояние.
8. Стратегия определяет семейство алгоритмов, инкапсулирует каждый для взаимозаменяемости. Благодаря чему изменение алгоритма не подвергается влиянию клиентов, которые его используют.
Пример: Утиный класс с инкапсулированным поведением, таким как Flybehavior для полёта и Quackbehavior для кряканья.
9. Наблюдатель устанавливает объектную зависимость «один ко многим» следующим образом: когда состояние главного объекта изменяется, зависимые уведомляются и получают автоматическое обновление.
10. Шаблонный метод задаёт каркас алгоритма операции, делегируя некоторые шаги дочерним классам. Дочерние классы переопределяют конкретные этапы алгоритма и оставляют его структуру неизменённой.
11. Посетитель добавляет новую функциональность классу без изменений.
Композиция против агрегации
Агрегация и композиция – сильные формы ассоциации, которые описывают отношения между целым и его частями. Таким образом, вместо отношения «имеет», как у обыкновенной ассоциации, получаем отношение «это часть» или в обратном направлении – «состоит из».
Примеры такого вида связей:
Композиция ещё сильнее агрегации. Для проверки типа связи используйте правило единственного использования для композиции: часть принадлежит только одному целому.
Для примера №1 и №2 музыкант или продукт принадлежит только одному оркестру или каталогу? Да! Но может ли в примере №3 комната принадлежать двум зданиям? Нет! Сработало правило единственного использования. Таким образом, отношение №3 лучше описывается композицией, чем агрегацией.
Вот другое правило для композиции: если целое уничтожено, уничтожается ли его часть?
Только для случая №3 работает дополнительное правило композиции. Если оркестр распадётся, исчезнут ли музыканты? Нет!
Пример кода: в университете масса факультетов, в каждом из которых группа профессоров. Если университет закроется, факультетов больше не будет, но профессора останутся. Следовательно, университет – композиция факультетов, а у факультетов агрегация профессоров. Кроме того, профессор может работать не только на одном факультете, но а факультет не может быть частью двух университетов.
1. Университет – факультет: композиция: собственность: уничтожаются вместе: сильное отношение «имеет».
Составной объект – владелец компонента и отвечает за создание и уничтожение частей. Компонент – часть одного составного объекта, уничтожение которого ведёт к ликвидации частей.
Композиция гарантирует инкапсуляцию, поскольку части – члены составного объекта:
2. Факультет – профессора: агрегация: нет собственности: отдельное существование: у компонента остаётся слабое отношение «имеет».
В агрегации объект содержит только ссылку или указатель на объект. Объект не отвечает за ссылку или указатель на протяжении всего жизненного цикла:
Полный пример кода и диаграмма:
В UML композиция изображается в виде закрашенного ромба и сплошной линии. Это говорит о кратности 1 или 0…1, то есть ответственность за объект несёт только один объект. Агрегация обозначается в виде пустого ромба и сплошной линии.
Наследование против композиции
Оба способа применяют для многократного использования функциональности.
Наследование
Композиция
С помощью наследования реализуют один класс на базе другого. В альтернативной композиции новая функциональность получается при составлении объекта. В результате получаем сокрытие внутренних деталей объектов, чего нет в наследовании.
Минусы наследования
Хотя наследование классов облегчает модификацию, реализация подкласса становится слишком связанной с родительской. В результате любая правка в реализации родителя затрагивает подкласс.
Посмотрите на пример:
Однако, если изменить метод makeSound() родительского класса, вот так:
Как насчёт композиции
При использовании композиции подкласс становится front-end классом, а суперкласс – back-end классом. При наследовании подкласс автоматически наследует реализацию любого неприватного метода суперкласса, если не переопределяет его. С композицией, однако, front-end класс явно вызывает соответствующий метод back-end класса из собственной реализации метода. Этот явный вызов иногда называется переадресацией или делегированием вызова метода back-end объекту.
Композиция даёт больше инкапсуляции, чем наследование, потому что изменение back-end класса не нарушает код, полагающийся на front-end класс. При наследовании подкласс знает детали реализации родителя и своеобразно вредит инкапсуляции.
Пример показывает, что цепная реакция от изменения back-end класса останавливается на front-end классе.
Композиция помогает сохранять каждый класс инкапсулированным и ориентированным на одну задачу. Классы и иерархии классов останутся маленькими и не разрастутся до неуправляемости.
Однако в проекте на базе композиции большее количество объектов (при уменьшении классов) и глобальное поведение опирается на их взаимосвязи, а не объявляется в одном классе.
Чаще используйте композицию.
Делегирование
Делает использование композиции для переиспользования равным по мощности наследованию. В делегировании два объекта участвуют в обработке запроса. Принимающий объект поручает действия делегату, что похоже на случай, когда подкласс доверяет запросы родительскому классу.
Основное преимущество делегирования в лёгкости объединения поведения во время выполнения. Например, превратим Window в круг рантайм:
Выбирайте делегирование, только когда больше упрощения, чем усложнения. Динамическое и параметризованное программное обеспечение сложнее в понимании, чем статичное, и добавляется проблема неэффективности во время выполнения. Поэтому используйте делегирование с умом, например, следуя стандартным паттернам проектирования, таким как Стратегия.
А вы используете паттерны проектирования при разработке? Выбираете композицию или наследование?
Что такое шаблоны проектирования?
Вы когда-либо задавались вопросом, что такое шаблоны проектирования? В этой статье будет разъяснено, почему шаблоны проектирования имеют существенное значение, и будет приведено несколько примеров на PHP, поясняющих, когда и где их следует использовать.
Шаблоны проектирования — это допускающие многократное использование оптимизированные решения проблем программирования, с которыми мы сталкиваемся каждый день. Шаблон проектирования — это не класс или библиотека, которые мы можем просто вставить в нашу систему. Он — много больше. Это — некоторый шаблон, который должен быть реализован в надлежащей ситуации. Он не зависит от языка. Хороший шаблон проектирования должен быть таким, чтобы его можно было использовать с большинством языков (если не со всеми) в зависимости от характеристик языка. Чрезвычайно важно то, что любой шаблон проектирования необходимо использовать очень осторожно — если он применён в ненадлежащем месте, то его действие может быть разрушительным и породить много проблем для вас. Однако применённый в нужном месте в нужное время он может стать вашим спасителем.
Есть три основных типа шаблонов проектирования:
• структурный
• порождающий
• поведенческий
Структурные шаблоны, в общем случае, имеют дело с отношениями между объектами, облегчая их совместную работу.
Порождающие шаблоны обеспечивают механизмы инстанцирования, облегчая создание объектов способом, который наиболее соответствует ситуации.
Поведенческие шаблоны используются в коммуникации между объектами, делая её более лёгкой и гибкой.
Почему их следует использовать?
Шаблоны проектирования в принципе являются хорошо продуманными решениями проблем программирования. Многие программисты уже сталкивались ранее с этими проблемами и использовали для преодоления эти «решения». Встречая какую-то проблему, зачем заново искать решение, когда можно применить уже проверенное?
Пример
Давайте представим, что вам поручено создать способ объединить два класса, которые выполняют два разных действия в зависимости от ситуации. Эти два класса интенсивно используются существующей системой в разных местах, что затрудняет их удаление и изменение существующего кода. Дополнительно к этому изменение существующего кода требует проверки всего изменённого кода, т.к. правка такого рода в системе, построенной на разных компонентах, почти всегда вносит новые ошибки. Вместо перечисленного можно использовать вариант шаблона «Стратегия» и шаблона «Адаптер», которые могут легко обращаться с названными типами сценариев.
Довольно просто, не так ли? Теперь посмотрим внимательнее на шаблон «Стратегия».
Шаблон «Стратегия»
Изображение размещено с разрешения владельцев сайта cioinnervoice.wordpress.com
Шаблон «Стратегия» является поведенческим шаблоном проектирования, который позволяет вам решать, какой план действий должна принять программа, основываясь на определённом контексте при выполнении. Вы закладываете два различных алгоритма внутри двух классов и решаете в ходе выполнения, с какой стратегией следует работать.
В нашем примере выше стратегия устанавливается в зависимости от того, какой была переменная $context в то время, когда класс подвергался обработке. Если вы даёте ей контекст для класса_один, то будет использован класс_один и наоборот.
Замечательно, но где я могу использовать это?
Предположим, что вы в данный момент разрабатываете класс, который может или обновить или создать новую пользовательскую запись. Хотя ему требуются те же самые входы (имя, адрес, номер мобильного телефона и т.п.), но в зависимости от ситуации он должен использовать различные функции при обновлении и создании. Здесь для выполнения можно, вероятно, сразу же использовать условный переход «if-else», но как быть, если этот класс понадобится и в другом месте? Тогда нужно будет переписать полностью весь этот оператор условного перехода. Не было бы проще просто указать ваш контекст?
Теперь «обычный» шаблон «Стратегия» предполагает помещение ваших алгоритмов внутри другого класса, но в данном случае другой класс был бы нерациональным решением. Помните, что вы не обязаны точно следовать шаблону. Варианты работают, пока концепция остаётся прежней, и это решает проблему.
Шаблон «Адаптер»
Изображение размещено с разрешения владельцев сайта www.uxcell.com
Шаблон «Адаптер» является структурным шаблоном проектирования, который позволяет перепрофилировать класс с другим интерфейсом, делая его доступным для системы, которая использует различные методы вызова.
Это также позволяет изменять некоторые из входов, получаемых от класса клиента, превращая его в нечто совместимое с функциями класса Adaptee.
Как можно использовать это?
Другим понятием для ссылки на класс адаптера является «обёртка», которая по существу позволяет «обернуть» действия в класс и повторно использовать эти действия в надлежащих ситуациях. Классическим примером может быть создание доменного класса для классов таблиц. Вместо вызова различных классов таблиц и последовательного вызова их функций можно вложить все эти методы в один, используя класс адаптера. Это не только позволяет вам повторно использовать любые требуемые действия, но также избавляет от необходимости переписывать код, если вам нужно использовать то же действие в другом месте.
Сравните эти две реализации:
Подход без адаптера
Если бы нам нужно было сделать это снова в другом месте или даже использовать этот код в другом проекте, то мы должны были бы набрать всё заново.
Лучше
Указанное противоположно действиям вроде приведённых ниже:
В данной ситуации мы имеем обёрточный класс, который был бы нашим доменным классом Account:
Таким образом, можно использовать домен Account снова везде, где требуется, — дополнительно вы оказываетесь в состоянии обёртывать другие классы также под вашим доменным классом.
Шаблон «Фабричный метод»
Изображение размещено с разрешения владельцев сайта www.lankanewspappers.com
Шаблон «Фабричный метод» является порождающим шаблоном проектирования, который делает именно то, что означает это слово: этот класс действует как фабрика экземпляров объектов.
Основной целью этого шаблона является вложение порождающей процедуры, которая может свести различные классы в одну функцию. Если фабричному методу обеспечить надлежащий контекст, то он будет в состоянии вернуть правильный объект.
Когда можно использовать это?
Наилучшей ситуацией для использования шаблона «Фабричный метод» является наличие нескольких различных вариантов одного объекта. Допустим, имеется класс «кнопка»; у этого класса есть различные варианты — например, ImageButton (кнопка изображения), InputButton (кнопка ввода) и FlashButton (флэш-кнопка). В зависимости от места может потребоваться создать различные кнопки — именно здесь можно использовать «фабрику» для создания кнопок для вас!
Начнём с создания наших трёх классов:
Теперь можно создать наш фабричный класс:
Полученный код можно использовать, например, так:
Выходом должен быть HTML всех ваших типов кнопок. Таким образом, вы могли бы указать, какую кнопку создать в зависимости от ситуации, а также повторно использовать условие.
Шаблон «Декоратор»
Изображение размещено с разрешения владельцев сайта www.decoratorsdarlington.co.uk
Шаблон «Декоратор» является структурным шаблоном проектирования, который позволяет нам добавлять новое или дополнительное поведение к объекту в ходе выполнения в зависимости от ситуации.
Целью является сделать так, чтобы расширенные функции могли быть применены к одному конкретному экземпляру и в то же время иметь возможность создать оригинальный экземпляр, который не имеет этих новых функций. Это также позволяет комбинировать несколько декораторов для одного экземпляра, благодаря чему отсутствует привязка к одному декоратору для каждого экземпляра. Этот шаблон является альтернативой созданию подкласса, что относится к созданию класса, который наследует функциональность от родительского класса. В противоположность к созданию подкласса, которое добавляет поведение во время компиляции, «декорирование» позволяет добавить новое поведение в ходе выполнения, если ситуация требует этого.
Чтобы реализовать шаблон «Декоратор», можно выполнить следующие шаги:
1. Выделите оригинальный класс «Компонент» как подкласс класса «Декоратор».
2. В классе «Декоратор» добавьте указатель «Компонент» как поле.
3. Переместите «Компонент» в конструктор «Декоратора», чтобы инициализировать указатель «Компонент».
4. В классе «Декоратор» перенаправьте все методы «Компонент» на указатель «Компонент».
5. В классе «Декоратор» отмените любой метод (любые методы) «Компонент», поведение которого (которых) должно быть модифицировано.
Данные этапы размещены с разрешения владельцев сайта en.wikipedia.org/wiki/Decorator_pattern
Когда можно использовать это?
Наиболее удобно использовать шаблон «Декоратор» для объекта, требующего нового поведения, только когда на это имеется запрос по ситуации. Допустим, имеется HTML-элемент компоновки, ссылка на выход из системы, и вы желаете, чтобы она делала немного различающиеся действия, основываясь на текущей странице. Для этого можно использовать шаблон «Декоратор».
Сначала зададим различные требуемые «декорации»:
• Если мы находимся на главной странице и зарегистрированы, то эта ссылка должна быть «обёрнута» в теги h2.
• Если мы находимся на другой странице и зарегистрированы, то эта ссылка должна быть «обёрнута» в теги подчёркивания.
• Если мы зарегистрированы, то эта ссылка должна быть «обёрнута» в теги полужирного шрифта.
После задания наших «декораций» можно их запрограммировать:
Затем мы должны быть в состоянии использовать это, например, следующим образом:
Здесь можно видеть, как мы оказываемся в состоянии скомбинировать несколько декораторов, если это требуется. Поскольку все декораторы используют магическую функцию __call, то мы можем всё ещё вызвать методы оригинальной функции. Если принять, что мы в настоящий момент находимся внутри главной страницы и зарегистрированы, то HTML-выход должен быть следующим:
Шаблон «Одиночка»
Изображение размещено с разрешения владельцев сайта intoxicologist.wordpress.com
Шаблон проектирования «Одиночка» является порождающим шаблоном проектирования, который обеспечивает наличие одного единственного экземпляра какого-то конкретного класса во время выполнения и глобальную точку доступа к этому единственному экземпляру.
Это облегчает задание точки «координации» для других объектов, также использующих данный единственный экземпляр, поскольку его переменные будут неизменными для любых вызовов.
Когда можно использовать это?
Сделав так, мы можем получать доступ к нашему экземпляру сеанса из различных частей нашего кода, даже в разных классах. Эти данные будут сохраняться в течение всех вызовов getInstance.
Заключение
Имеется ещё много шаблонов проектирования, которые полезно знать; в этой статье я остановился только на некоторых из наиболее известных, которые я использую при программировании. Если есть интерес прочитать о других шаблонах проектирования, то страница Википедии Design Patterns (Шаблоны проектирования) содержит много информации об этом. Если этого недостаточно, то вы всегда можете прочитать книгу «Design Patterns: Elements of Reusable Object-Oriented Software» («Шаблоны проектирования: элементы многократно используемого объектно-ориентированного программного обеспечения»), которая считается одной из лучших по рассматриваемой теме.
И последнее: используя эти шаблоны проектирования, всегда проверяйте, что вы пытаетесь решить правильно поставленную задачу. Как я упоминал ранее, эти шаблоны проектирования необходимо использовать очень осторожно: они — при использовании в ненадлежащем контексте — могут ухудшить ситуацию, но при правильном использовании они просто жизненно необходимы.
Если вы нашли данную статью полезной, то почему бы не ознакомиться с предложением PHP-скриптов на Envato Market. Там представлены тысячи полезных скриптов, которые могут ускорить вашу разработку и улучшить конечный результат. Имеются системы бронирования, контактные формы AJAX, системы информационных бюллетеней и многое другое.