Введение в архитектуру и паттерны программирования

Статистика: Символов — 9 119/7 861 без пробелов (8 947/7 711 без кода):, слов — 1 237
Разметка: Wiki
{{TOC}}

==Введение==

Прежде чем заняться разработкой собственного проекта на основе ((2 каркаса)) приложения Laravel, нам неплохо было бы понять //архитектуру каркаса приложения//. Некоторые могут спросить: Зачем это нужно? Смысл забивать себе голову разной теоретической чепухой?
Постараюсь ответить на этот вопрос примером из жизни:

Представьте себе, что вы хотите иметь эксклюзивный автомобиль. Естественно он будет строиться на базе некоей серийной модели, но для того, чтобы его построить вам потребуется помощь людей, которые умеют это делать. Вы решаете обратиться к мастерам или даже к фирмам, у которых есть все необходимое: знания, опыт, оборудование и инструмент, но их услуги не дешевы, Ваш бюджет просто не выдержит таких расходов. Тогда вы решаете, что будете строить автомобиль самостоятельно. Отличное решение - правда, вы берете в руки инструмент, плюете на изучение теории, внедряете свои задумки и в итоге…

Я думаю, не стоит описывать, что у вас получится в итоге, ясно только одно - ничего хорошего.

Ну и более приближенный к теме Laravel 4 ответ: Понимание //архитектуры приложения//, знание основ //((ВП:Шаблон проектирования==паттернов (шаблонов) проектирования))//, помогут вам понять, почему следует использовать именно этот каркас web-приложения, оценить его слабые и сильные стороны. Так же вы получите ответ, почему так сильно изменился Laravel 4 по сравнению с Laravel 3.

Для тех, кто все же решил изучить теорию, прежде чем приступить к практике, советую: запаситесь терпением.

После прочтения статьи  не останавливайтесь на достигнутом, в сети много ресурсов, где можно почерпнуть нужную информацию по паттернам. Поверьте, зная, что такое паттерны, их конкретные реализации и как их использовать, можно добиться намного большего, чем оставив эту тему за пределами багажа своих знаний…

==Определения==

  * //Архитектура приложения// - это логическая структура, описывающая отдельные компоненты, их свойства и связи в виде единой системы.
  * //Паттерны// - это описания схем детализации отдельных подсистем приложения и взаимосвязей между ними. При этом паттерны не являются частью программы, не влияют прямо на ее структуру и сохраняют полную независимость от языка программирования конкретной системы.
  * ((ВП:Model-View-Controller MVC)) - программная //((ВП:парадигма)) архитектурных паттернов//: модель - представление - контроллер.

==Паттерны это не так сложно как кажется==

Если Вы спокойно и уверенно ориентируетесь в паттернах и парадигмах, то смело можете пропускать эту часть статьи. Но если, читая определения, Вы чувствуете, что это просто набор слов, то не поленитесь прочитать представленный ниже материал. Я надеюсь, он поможет вам разобраться в этой не очень простой для многих программистов теме и начать использовать паттерны в своей работе.

На самом деле паттерны не так сложны для понимания, как кажется на первый взгляд. Давайте проиллюстрируем их примерами, все сразу станет намного понятнее.

Итак, представьте, что вам необходимо разработать сложное приложение представлявшее каркас диалога и передачи данных между людьми, абстрактными Васей и Петей. Вначале мы рассмотрим простую программу того как Вася и Петя будут общаться между собой и производить обмен информацией:

  1. Вася и Петя встретились.
  2. Вася протянул Пете руку.
  3. Петя сказал "Здравствуй Вася".
  4. Вася ответил "Здравствуй Петя".
  5. Вася спросил "Ты принес мне диск с курсовой?".
  6. Петя ответил "Да, принес".
  7. Вася полез в карман и достал деньги.
  8. Вася отсчитал 100$.
  9. Вася передал деньги Пете.
  10. Петя принял деньги от Васи.
  11. Петя пересчитал деньги.
  12. Петя кивнул головой - подтверждая, что сумма соответствует цене за диск.
  13. Петя положил деньги в карман.
  14. Петя достал диск.
  15. Петя передал диск Васе.
  16. Вася принял диск от Пети.
  17. Вася положил диск в карман.

Теперь разобьём эту программу на отдельные части:

  1. Начало программы.
  2. Встреча.
  3. Обмен приветствиями.
  4. Проверка наличия "данных".
  5. Передача данных "деньги".
  6. Списание данных "деньги".
  7. Проверка данных "деньги".
  8. Запись данных "деньги".
  9. Передача данных "диск".
  10. Списание данных "диск".
  11. Запись данных "диск".
  12. Конец программы.

У нас получился //алгоритм// действий для встречи и обмена диска на деньги между двумя индивидуумами.

Теперь разбиваем алгоритм на составляющие так:

  1. Общение.
  2. Обмен данными.
  3. Проверка условий.
  4. Действия.

У нас как раз и получился набор паттернов (правда очень абстрактный). Зато этот архитектурный паттерн или программная парадигма  описывает обмен данными практически любого вида и любой сложности. По сути это аналог  всем известного MVC.

Если же мы решим разработать универсальную программу для взаимодействия двух человек, то нам будет недостаточно такого куцего описания. Точнее нам к архитектурному паттерну понадобиться добавить паттерны, которые расширят описание реализации взаимодействия всех частей архитектурного паттерна.

Давайте попробуем составить схему таких паттернов самостоятельно:

  1. Общение
    a. Установление контакта
    b. Передача запросов между пользователем и системой
  2. Обмен данными
    a. Передача данных запроса в направлении в систему
    b. Передача данных запроса в направлении  из системы
    c. Передача команд на проверку условий
    d. Передача команд на передачу данных
  3. Проверка условий
    a. Проверка условий передачи данных
    b. Подтверждение проверки условий
  4. Действия
    a. Извлечение данных из хранилища "А"
    b. Передача данных в хранилище "А"

В итоге у нас получилась своя схема паттернов.

Теперь, если мы опишем, как конкретно взаимодействуют наши паттерны между  собой - то получим рабочие паттерны. Причем паттерны будут достаточно универсальными, чтобы на их основе писать приложения не только для общения людей, но и для общения инопланетян.

Если на  основе наших паттернов написать приложение - получим каркас приложения для реализации общения, причем этот каркас можно будет очень легко модифицировать, так как он имеет очень детальную, хорошо продуманную  и описанную структуру. Так же на основании нашего каркаса любой разработчик сможет легко написать собственное приложение для общения людей или компьютеров, или даже инопланетян. Ведь ему не нужно будет вникать в тонкости реализации взаимодействия компонентов нашего каркаса, ему будет достаточно знать общую структуру паттернов - архитектуру каркаса приложения, для того, чтобы составить свои правила общения, обмена данными, проверки условий и действий...

==Паттерны бывают разными==

Давайте теперь немного углубим наши знания. Дело в том, что паттерны бывают не только архитектурными, на самом деле у паттернов есть несколько //классификаций//.

  * //Классификация по масштабу//
  * //Классификация по стилю//
  * //Классификация по применению//

===Классификация по масштабу===

Самая часто используемая классификация - это классификация по масштабу. Чаще всего она применяется для паттернов проектирования и делится на три слоя по детализации:

  * //Архитектурные паттерны// - наивысший слой детализации, используются для описания структуры программы в целом.
  * //Паттерны проектирования// - средний слой детализации, описывают компоненты отдельных архитектурных паттернов и реализацию их взаимодействия.
  * //Идиомы// - низший слой детализации, описывают реализацию отдельных решений проблем применительно к конкретному языку программирования. Следует учитывать, что зачастую идиомы для различных языков программирования имеют различную реализацию, или не имеют таковой вовсе. Примером могут служить указатели в памяти для реализации в //Assembler//, они имеют абсолютно другую реализацию в //Си// и не имеют реализации  в //С#//, так как там проблема с утечкой памяти не существует ибо есть ((ВП:сборщик мусора==))...

===Классификация по стилю===

  * //Порождающие паттерны// - предназначены для решения проблем создания новых объектов и связей.
  * //Структурные паттерны// - предназначены для компоновки системы, при этом могут использовать различные механизмы, такие как //((ВП:Наследование (программирование)==наследование))//, //((ВП:Полиморфизм (программирование)==полиморфизм))//, //((ВП:Агрегирование (программирование)==композиция))//. Кстати, принципы  классов построены как раз на структурных паттернах.
  * //Паттерны поведения// - предназначены для решения задач связи объектов  и распределения задач между ними.

===Классификация по применению===

Программистам редко приходится сталкиваться с данным классом паттернов, но все же стоит о нем упомянуть, чтобы иметь хотя бы общее представление. Это самый высокоуровневый класс паттернов. В него входят целые классы паттернов. Например:

  * //Паттерны тестирования//
  * //Паттерны документирования//
  * //Паттерны организации производственных процессов//
  * //Паттерны организации рабочих мест//

И многие другие. Но я надеюсь их уже не нужно расписывать, вы вполне теперь способны продолжить этот список и без моих подсказок.

==Заключение==

Какие преимущества дают нам паттерны? Отвечу на этот вопрос, цитируя ((ВП:John Vlissides==)) ([[ВП:Джон Влиссидес==]]):

<[
  Паттерны суммируют опыт множества разработчиков и экспертов, делая его доступным рядовым разработчикам.
  Именование паттернов позволяют создать своего рода словарь, с помощью которого разработчики могут понять друг друга намного лучше.
  Если в документации к системе указано,  на основе каких паттернов она построена, это позволяет  быстрее понять структуру системы.
]>

Правильно подобранные  паттерны проектирования позволяют сделать программную систему более гибкой, ее легче поддерживать и модифицировать, а код такой системы в большей степени соответствует концепции повторного использования.

Для тех, кого заинтересовали паттерны, советую найти и почитать книги:

  * Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес: Приемы ООП. ((гугл:Паттерны проектирования==)).
  * Джон Влиссидес: ((гугл:Применение шаблонов проектирования==)). Дополнительные штрихи.