За всё время работы программистом, я сталкивался с различными задачами по доработке сайтов. И отметил одно: функций много, общей картины не видно, где то (например в yii) нужно ещё инициировать проект, чтобы через phpmyadmin увидеть актуальные таблицы… я не говорю уже о целях и требованиях, которые почему то в проектах бесследно исчезают.

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

Мой путь

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

Четыре важных компонентов построения сайта

1. Conditions
2. Space
3. Distribution
4. Realization

Этот подход основательно выявил текущий принятый ООП в php как беспорядочную муть.

В чём фишка текущего ООП? Да, распиаренный Родитель-сын. А какие цели стояли для ООП? Разве необходимость разместить готовые алгоритмы по разным файлам в виде class? Не думаю, это усугубляет только. Разве стояла цель создать семейственность? Не думаю, уже создав 4-е класса можно запутать кто чей папа.

Проблемы текущего ООП на php

1. Огрызки пространства имён
2. Много файлов
3. Допускается вариант «повтор-функции»

Простите, но это критические ошибки, мешающие работе проектировщика. А team-lead чем хвастается перед директором? Функциями? Что то тут неправильно.

ООП посредством компонентов CSDR

1. Conditions

Создания сайтов начинаются с головы. А это цели. Мы конечно же уже профи, и понимаем, что прежде чем начать выполнять цели — нужно взять 30% предоплаты. Шучу. Конечно же нужно провести все необходимые расчёты, дабы проект в итоге был сбалансированным, и соответствовал всем требованиям построения сайта, и целям тоже.

Цель: ООП посредством CSDR на примере мини-офиса

Требования к основе: - Три роли: директор (1 человек), секретарь (1 человек), программисты (2 человека) - Директор умеет: ставить задачи (2 задачи), анализировать отчёт, хвалить программиста ...

Результат работы должен вывести на экран такой шаблон текста:  {дата-время} Директор постановил задачу: {задача} {дата-время} Программист {инициалы} создал код: {код} ...

2. Space

Требования утверждены. Начинаем проектировать. Вот тут дамы и господа, и те, кто против диктаторства: начинается создание пространства имён. Неожиданно, да? Да. Берём и начинаем создавать массив имён мест (это те самые имена, которыми вы называете классы и функции), с построением иерархии (вложенности). Есть важный момент космос-построения, нужно так же писать и суть места, описывать для чего предназначены места. Не переживайте, внизу будет наглядный пример. Кстати, пространства имён должны быть не только мест, но и переменных, а так же и таблиц базы данных. Да-да. Эти места создаются заблаговременно, творцы. 🙂

$GLOBALS['Пространство мест'] = [     'п.м. 1' => [         'Название' => 'Директор',         'Смысл' => 'Место директора',         'п.м. 1.1' => [             'Название' => 'Постановка задачи',             'п.м. 1.1.1' => [                 'Название' => 'Легкая',                 'Смысл' => 'Место, где директор может постановить программисту легкую задачу',             ],             'п.м. 1.1.2' => [                 'Название' => 'Трудная',                 'Смысл' => 'Место, где директор может постановить программисту трудную задачу',             ],         ], ...

$GLOBALS['Пространство переменных'] = [     'п.п. 1' => [         'Название' => 'Работа',         'Смысл' => 'Переменная, где идут рабочие процессы',         'п.п. 1.1' => [             'Название' => 'Задача',             'Смысл' => 'Переменная, где содержится задача для программистов',         ], ...

3. Distribution

Пространство создано. Начинаем распределять. Слышали, что раньше окно и двери вырубали в цельной деревянной стене? Вот, здесь так же: пространство это стены, а распределение это уже двери. Создаём массив, где для каждого места будет свои входящие переменные, и выходящие переменные. Стоп. Если вы не сбалансировали проект, идите ка вы на пункт номер один. А коли сбалансировали, то вы конечно же уже знаете, что нужно кому дать, а у кого чего взять. Так и указываете в массиве, а так же допишите какой толк с этого. Выгода должна быть объявлена, однако. 🙂

$GLOBALS['Элементы'] = [     'э. 1' => [         'Пространство места' => 'п.м. 1.1.1',         'Толк' => 'Директор даст лёгкую задачу',         'Входящие переменные' => [         ],         'Выходящие переменные' => [             'п.п. 1.1',         ],     ], ...

4. Realization

Элементы (палка о двух концах) образованы. Теперь дело за алгоритмами. Да, я не ошибся, именно алгоритмами, а не функциями. Берём и пишем одну функцию run_the_algorithm, а внутри через условия «if-elseif» дописываем все алгоритмы. Вот так вот.

function run_the_algorithm($parameters = ['Элемент' => null, 'Входящие переменные' => null]){      $e = $parameters['Элемент'];     $p = $parameters['Входящие переменные'];      /*Действие: директор постановляет лёгкую задачу*/     if($e == 'э. 1'){          return [             'п.п. 1.1' => 'Создай скрипт'         ];      } ...

5. Conditions

Да, это не конец. Систематизируем новые действия в итоговые сведения.

Готовые алгоритмы: 1) Директор постановляет лёгкую задачу: run_the_algorithm(['Элемент' => 'э. 1', 'Входящие переменные' => null]) ... 

Только после этого допустимо внедрение алгоритмов в рабочий процесс.

foreach(['э. 1', 'э. 2'] as $p){      $r = run_the_algorithm(['Элемент' => $p, 'Входящие переменные' => null]);      $t = $r['п.п. 1.1'];      run_the_algorithm(['Элемент' => 'э. 10', 'Входящие переменные' => ['п.п. 3' => 'Директор постановил задачу: ' . $t]]);      foreach(['э. 6', 'э. 7'] as $pr){ ... 

Такой подход намного упрощает жизнь. Система становится наглядной, взаимозависимой и распределенной… легко видно где именно допущена любая ошибка, которую можно уже назвать одним словом: «пренебрежение». Зараза ещё та. 🙂

Ну собственно и полный пример.

Хорошая архитектура — это дорого. Плохая — еще дороже.