Дисклеймер: этот текст меня заставило написать практически полное отсутствие вменяемых материалов по данной теме на русском языке. Этому плохо учат в вузах, об этом молчат самоучители PHP и официальный мануал, хотя это самый важный момент при разработке программы — создание архитектуры. Плохая архитектура может убить ваш проект, так что он никогда не увидит свет. Хорошая архитектура даже при плохом коде, а кто из новичков пишет хороший код, способна творить чудеса.
Разработка архитектуры должна начинаться в тот момент, когда вам в голову пришла идея «хочу сайт такой-то» или кто-то вложил идею «нужен сайт такой-то». К сожалению, большинство разработчиков сразу приступают к написанию кода, причём даже не того, какого нужно.
Прежде чем писать код, вооружитесь листочком с ручкой, вордпадом, вордом, райтером или даже вашим редактором кода и выполните пару шагов.
Архитектура разрабатывается сверху вниз. Что это значит? Это значит, что сперва вы продумываете самые главные подсистемы, прежде чем приступить к обслуживающим их или более техническим.
Многие программисты начинают разработку сайтов с роутеров, подключения к БД, обработки ошибок, что приводит к необходимости переписывания их кода в будущем или обильной вставке в код костылей, как только они натыкаются на то, что не смогли предусмотреть.
Всё предусмотреть невозможно, для этого и нужно разрабатывать систему сверху вниз. Наличие работающих высокоуровневых классов практически автоматически определяет все необходимые требования к обслуге.
Это не единственный метод, но по опыт знаю, что самый оптимальный для тех, кто не чувствует себя, как рыба в воде среди паттернов проектирования или даже совсем про них не знает.
Итак, вам нужен блог, интернет-магазин, сайт стоматологической клиники.
Определитесь, что на вашем сайте самое главное, ради чего всё затевается.
Для блога — это, очевидно, записи. Для магазина — товары. Для сайта поликлиники — услуги.
Уже можем написать немного кода, с которого и начнётся разработка сайта:
или class товары {}, или class услуги{}
Это ваша главная подсистема. Сразу же можно написать, чем именно она будет управлять.
или class товар {}, или class услуга{}
Мы создали главную подсистему «записи». Следующий шаг: определить, что она будет уметь, чему мы хотим научить наш сайт.
Очевидно, она должна уметь создавать записи, удалять записи и получать записи.
Забудьте, что вы пишите код сайта, забудьте про пользователей, url-адреса, оформление страниц. Работайте с голыми данными: строками, числами, массивами, объектами.
Пишем код:
Что такое запись? Что такое услуга? Что такое товар? Для вас, как программиста — это просто совокупность данных. В третьем шаге определяем, что это за совокупность.
Не стремитесь предусмотреть всё, что понадобится когда-то в будущем. Берите самый-самый минимальный набор. Для этого мы и строим архитектуру приложения, чтобы в будущем её было легко нарастить.
Очевидно, запись — это заголовок и текст записи. Услуга и товар — название, описание и цена.
Компьютер — не очень умное создание, по сравнению с человеком, вы не сможете сказать ему: «а покажи-ка мне запись, ту, где про зелёного котёнка написано», поэтому ему всегда необходим какой-то уникальный код, чтобы он среди множества записей узнал именно ту, которую вы хотите.
Это либо порядковый номер (id), уникальный для каждой записи или некое, столь же уникальное, строковое значение.
Значит наша запись — это идентификатор записи (id), заголовок, текст.
Больше нам ничего не нужно.
Теперь для каждого действия системы нам нужно понять, что системе нужно знать, чтобы это действие выполнить.
Для действия «создать_запись» нужно знать заголовок и текст записи. Внутренний идентификатор нужен только компьютеру, поэтому пусть сам его и придумывает.
Для действий «удалить_запись» и «получить_запись» нужно знать только тот самый идентификатор записи, который был ей присвоен компьютером при создании.
То, что получилось называется интерфейсом вашего класса/модуля/подсистемы.
Также, как мы узнали необходимые знания для выполнения того или иного действия, нужно понять, чем эти действия будут оканчиваться.
Если у компьютера всё получилось, то
Если у компьютера чего-то не получилось, то
Для всех ситуаций, когда что-то не получилось поведение программы должно быть одинаковым во всех модулях/классах/подсистемах вашей системы. PHP предоставляет всего два варианта: trigger_error и throw new Exception. Можете придумать свой, но не стоит изобретать велосипеды, пока вы не научились ездить на существующих. throw new Exception — самый оптимальный вариант.
Читайте раздел "исключения" в официальном мануале.
В шаге первом, кроме создания системы управления записями, мы создали ещё класс и самой записи: class запись {}
Для неё нужно сделать тоже самое, что и для главной, те же самые шаги с 1 по 5.
Если вы всё сделали правильно, то у вас должно получиться что-то похожее.
Теперь, когда всё создано можно приступать к кодированию. Если вы знакомы с PHP никаких проблем у вас не возникнет.
Сколько затратили времени? Совсем чуть-чуть, и ещё ощутите в будущем всюпользу от произошедшего.
То, что у вас получится в итоге скрывается под буквой M в страшной аббревиатуре MVC.
Я не учёл много нюансов, их хватит на десять таких же статей, но базис для вашей разработки уже есть. Это — самые основы и это в любом случае лучше, чем мешать PHP с HTML в одном файле или плодить кучу функций по мере написания кода.
C M разобрались. Что касается V и C. Это тема для других статей. Поэтому вкратце. Если вы достаточно сообразительны, то другие статьи вам и не понадобятся.
C — это место, в котором система реагирует на действия пользователя. Вот там и нужно думать, что будет делать пользователь. Захотел пользователь создать запись в блоге, заполнил форму создания, а у вас уже всё готово, чтобы выполнить его команду. Захотел, прочитать запись и снова вы выполняете его просьбу в одну строчку. Там главная задача (шаг 1) — понять, что хочет пользователь.
V — изучите любой шаблонизатор: Smarty или Twig. Много споров ведётся про то использовать шаблонизаторы или нет, много убедительных доводов с той и с другой стороны. Правда в том, что для web-разработчика непростительно не уметь работать с шаблонизаторами. Поэтому осваивайте их, а потом уже откажетесь, если не понравится.
Как уже было отмечено выше, на русском языке почти нет достойный литературы на эту тему.
Единственную книгу, которую могу посоветовать прочитать: Стив МакКоннелл «Совершенный код».
Если кто-то знает другие материалы киньте в меня ссылочкой. С удовольствием прочитаю и буду рекомендовать новичкам.
Разработка архитектуры должна начинаться в тот момент, когда вам в голову пришла идея «хочу сайт такой-то» или кто-то вложил идею «нужен сайт такой-то». К сожалению, большинство разработчиков сразу приступают к написанию кода, причём даже не того, какого нужно.
Прежде чем писать код, вооружитесь листочком с ручкой, вордпадом, вордом, райтером или даже вашим редактором кода и выполните пару шагов.
Шаг 1. Постановка главной задачи
Архитектура разрабатывается сверху вниз. Что это значит? Это значит, что сперва вы продумываете самые главные подсистемы, прежде чем приступить к обслуживающим их или более техническим.
Многие программисты начинают разработку сайтов с роутеров, подключения к БД, обработки ошибок, что приводит к необходимости переписывания их кода в будущем или обильной вставке в код костылей, как только они натыкаются на то, что не смогли предусмотреть.
Всё предусмотреть невозможно, для этого и нужно разрабатывать систему сверху вниз. Наличие работающих высокоуровневых классов практически автоматически определяет все необходимые требования к обслуге.
Это не единственный метод, но по опыт знаю, что самый оптимальный для тех, кто не чувствует себя, как рыба в воде среди паттернов проектирования или даже совсем про них не знает.
Итак, вам нужен блог, интернет-магазин, сайт стоматологической клиники.
Определитесь, что на вашем сайте самое главное, ради чего всё затевается.
Для блога — это, очевидно, записи. Для магазина — товары. Для сайта поликлиники — услуги.
Уже можем написать немного кода, с которого и начнётся разработка сайта:
class записи
{
}
или class товары {}, или class услуги{}
Это ваша главная подсистема. Сразу же можно написать, чем именно она будет управлять.
class запись
{
}
или class товар {}, или class услуга{}
Шаг 2. Определить, что ваша система умеет делать
Мы создали главную подсистему «записи». Следующий шаг: определить, что она будет уметь, чему мы хотим научить наш сайт.
Очевидно, она должна уметь создавать записи, удалять записи и получать записи.
Забудьте, что вы пишите код сайта, забудьте про пользователей, url-адреса, оформление страниц. Работайте с голыми данными: строками, числами, массивами, объектами.
Пишем код:
class записи
{
public function создать_запись() {}
punlic function удалить_запись() {}
public function получить_запись() {}
}
Шаг 3. Понять, с чем имеем дело
Что такое запись? Что такое услуга? Что такое товар? Для вас, как программиста — это просто совокупность данных. В третьем шаге определяем, что это за совокупность.
Не стремитесь предусмотреть всё, что понадобится когда-то в будущем. Берите самый-самый минимальный набор. Для этого мы и строим архитектуру приложения, чтобы в будущем её было легко нарастить.
Очевидно, запись — это заголовок и текст записи. Услуга и товар — название, описание и цена.
Компьютер — не очень умное создание, по сравнению с человеком, вы не сможете сказать ему: «а покажи-ка мне запись, ту, где про зелёного котёнка написано», поэтому ему всегда необходим какой-то уникальный код, чтобы он среди множества записей узнал именно ту, которую вы хотите.
Это либо порядковый номер (id), уникальный для каждой записи или некое, столь же уникальное, строковое значение.
Значит наша запись — это идентификатор записи (id), заголовок, текст.
Больше нам ничего не нужно.
Шаг 4. Определение необходимых знаний
Теперь для каждого действия системы нам нужно понять, что системе нужно знать, чтобы это действие выполнить.
Для действия «создать_запись» нужно знать заголовок и текст записи. Внутренний идентификатор нужен только компьютеру, поэтому пусть сам его и придумывает.
Для действий «удалить_запись» и «получить_запись» нужно знать только тот самый идентификатор записи, который был ей присвоен компьютером при создании.
class записи
{
public function создать_запись($заголовок, $текст) {}
punlic function удалить_запись($идентификатор) {}
public function получить_запись($идентификатор) {}
}
То, что получилось называется интерфейсом вашего класса/модуля/подсистемы.
Шаг 5. Определение результатов
Также, как мы узнали необходимые знания для выполнения того или иного действия, нужно понять, чем эти действия будут оканчиваться.
Если у компьютера всё получилось, то
- создать_запись: будет создана новая запись, а мы получим её идентификатор.
- удалить_запись: будет удалена конкретная запись, а мы получим сообщение 'готово'
- получить_запись: получим нужную запись
Если у компьютера чего-то не получилось, то
- создать_запись: будет выброшено исключение.
- удалить_запись: будет выброшено исключение
- получить_запись: будет выброшено исключение
Для всех ситуаций, когда что-то не получилось поведение программы должно быть одинаковым во всех модулях/классах/подсистемах вашей системы. PHP предоставляет всего два варианта: trigger_error и throw new Exception. Можете придумать свой, но не стоит изобретать велосипеды, пока вы не научились ездить на существующих. throw new Exception — самый оптимальный вариант.
Читайте раздел "исключения" в официальном мануале.
Шаг 6. Снова с начала
В шаге первом, кроме создания системы управления записями, мы создали ещё класс и самой записи: class запись {}
Для неё нужно сделать тоже самое, что и для главной, те же самые шаги с 1 по 5.
Если вы всё сделали правильно, то у вас должно получиться что-то похожее.
class запись
{
public function получить_идентификатор() {}
public function получить_заголовок() {}
punlic function получить_текст() {}
public function изменить_заголовок($новый_заголовок) {}
public function изменить_текст($новый_текст) {}
}
Шаг 7. Пишем код
Теперь, когда всё создано можно приступать к кодированию. Если вы знакомы с PHP никаких проблем у вас не возникнет.
Сколько затратили времени? Совсем чуть-чуть, и ещё ощутите в будущем всюпользу от произошедшего.
То, что у вас получится в итоге скрывается под буквой M в страшной аббревиатуре MVC.
Заключение
Я не учёл много нюансов, их хватит на десять таких же статей, но базис для вашей разработки уже есть. Это — самые основы и это в любом случае лучше, чем мешать PHP с HTML в одном файле или плодить кучу функций по мере написания кода.
C M разобрались. Что касается V и C. Это тема для других статей. Поэтому вкратце. Если вы достаточно сообразительны, то другие статьи вам и не понадобятся.
C — это место, в котором система реагирует на действия пользователя. Вот там и нужно думать, что будет делать пользователь. Захотел пользователь создать запись в блоге, заполнил форму создания, а у вас уже всё готово, чтобы выполнить его команду. Захотел, прочитать запись и снова вы выполняете его просьбу в одну строчку. Там главная задача (шаг 1) — понять, что хочет пользователь.
V — изучите любой шаблонизатор: Smarty или Twig. Много споров ведётся про то использовать шаблонизаторы или нет, много убедительных доводов с той и с другой стороны. Правда в том, что для web-разработчика непростительно не уметь работать с шаблонизаторами. Поэтому осваивайте их, а потом уже откажетесь, если не понравится.
Как уже было отмечено выше, на русском языке почти нет достойный литературы на эту тему.
Единственную книгу, которую могу посоветовать прочитать: Стив МакКоннелл «Совершенный код».
Если кто-то знает другие материалы киньте в меня ссылочкой. С удовольствием прочитаю и буду рекомендовать новичкам.
