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

Есть требование к читателям: данная статья для тех, кто ценит программирование на php. :)

Предыстория



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

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



Мой путь


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

Четыре важных компонента у объекта


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

Эти компоненты основательно выявили «ООП на классах» в php как некие зависания в каких то (не ясных) этапах разработок.

Зона неопределенности на классах


1. Нет целей и требований
2. Неструктурированно пространство имён
3. Неструктурированны файлы
4. Уравнивание разных по назначению алгоритмов

Простите, но это критические ошибки, мешающие подытожить проект.

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



image

1. Conditions


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

$GLOBALS['Цели'] = [
    'ц. 1' => [
        'Ориентир' => 'ООП посредством компонентов CSDR на примере мини-офиса',
        'Требования' => [
            'Требования к основе' => [
                'Три роли: директор (1 человек), секретарь (1 человек), программисты (2 человека)',
                'Директор умеет: ставить задачи (2 задачи), анализировать отчёт, хвалить программиста',
                ...
            ],
            'Требования к шаблонам' => [
                'Шаблон кода (1-16 случайных символов)',
                ...
            ],
            'Требования к результату' => [
                'Вывести на экран такой шаблон текста' => '
                    {дата-время} Директор постановил задачу: {задача}
                    {дата-время} Программист {инициалы} создал код: {код}',
                    ...
            ],

        ],
        'Результат' => false,
    ],
...


2. Space


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

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


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


3. Distribution


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

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


Для тестирования добавляем пример.

$GLOBALS['Элементы'] = [
    'э. 1' => [
        ...
        'Входящие переменные (пример)' => [
        ],
        'Выходящие переменные (пример)' => [
            'м.п. 1.1' => 'Создай скрипт',
        ],
        ...


И заполняем значения по умолчанию.

$GLOBALS['Содержание'] = [
    'м.п. 2.4' => 'Соколов В.М.',
    'м.п. 2.5' => 'Гагарин П.В.',
];


4. Realization


Элементы (палка о двух концах) образованы. Теперь дело за алгоритмами.

$GLOBALS['Алгоритмы'] = [
    'а. 1' => [
        'Элемент' => 'э. 1',
        'Действие' => 'Директор постановляет лёгкую задачу',
        'Функция' => function($parameters){
            return [
                'м.п. 1.1' => 'Создай скрипт'
            ];
        },
    ],
...


5. Conditions


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

$GLOBALS['Цели'] = [
    'ц. 1' => [
        'Ориентир' => 'ООП посредством компонентов CSDR на примере мини-офиса',
        'Требования' => [...],
        'Результат' => '$GLOBALS["Алгоритмы"]["а. 0"]["Функция"]([]);',
    ],
...


И внедряем в рабочий процесс.

eval($GLOBALS['Цели']['ц. 1']['Результат']);


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

Ну собственно и готовый пример: github.com/veter-love/easy-oop.framework-life-balance

— До встречи! Дальше думаю опишу интерфейс онлайн сборки сайта выше-описанной архитектуры. Возможно смогу воссоздать и сам прототип. :)
Tags:
чистый код, архитектура, ооп, php, классы, csdr

You can't comment this post because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author's username will be hidden by an alias.