Предисловие
За всё время работы программистом, я сталкивался с различными задачами по доработке сайтов. И отметил одно: функций много, по разных файлам разбросанно, общей картины пространства имён не видно, где то (например в yii) нужно ещё инициировать проект, чтобы через phpmyadmin увидеть актуальные таблицы… я не говорю уже о контроле созданного проекта, который не централизован вовсе (if,elseif где попало). А перевод на git технологии перевёл код на уровень: построили из того что было под рукой.
Не желавши такого, совсем, тянувшись к геометрии и балансу, я начал восстанавливать исконный подход к программированию, да так, чтобы можно было легко сдать сайт другому программисту на доработку, со всем необходимым.
Зона абы как
PHP-коды по методу «ООП на классах» я выявил как некие зависания в каких то (не ясных) этапах разработок. Раздрай какой то:
- Нет целей проекта и описаний
- Неструктурированно пространство имён
- Неструктурированны файлы
- Уравнивание разных по назначению алгоритмов
Свобода – это осознанная необходимость
Я утвердил что мой подход к программированию станет дисциплинированным и свободным. Не легко было, но я справился, и выявил 4-е важных компонента построения проекта (как для ядра, так и для интерфейса), которые полностью соответствовали моему устремлению:
- Conditions, где создаются права проекта
- Space, где создаются роли проекта
- Distribution, где создаются возможности проекта
- Realization, где создаются способности проекта
Зафиксируем эту аббревиатуру как CSDR.
Архитектура проекта на CSDR
Согласование
Первое, что нужно учесть: мы создаём проект (ядро или интерфейс). Второе: проект должен быть целостным. Думаю, как и я, вы посчитали эти условия разумными.
Проектирование
Далее из этого вытекает, что дальше речь будет о компонентах проекта, а по моим расчётам (и подсказкам таки еврейских братьев) наш мир 4-х-мерный: прошлое (наша опора), будущее (наша среда), объединяющее (таки да, торговля и подарки важны) и настоящее (наши дела). Основавшись на таких знаниях, и признав, что лучшего программирования согласованного с ходом нашего времени не найти, я спроектировал такие имена компонентов для создания проекта: Conditions, Space, Distribution и Realization.
Сделаю небольшой перевод аббревиатуры CSDR, для дальнейшего удобства изъяснений. Итак:
- Conditions, где создаются права проекта -> Рефлексы
- Space, где создаются роли проекта -> Места
- Distribution, где создаются возможности проекта -> Связи
- Realization, где создаются способности проекта -> Реакции
Объект
Связи предоставят реакциям (алгоритмам) все значения с необходимых мест (с типом переменная).
Проект
Когда же из компонентов начал создавать 4-х-мерный проект, то заметил, что рефлексы и места из за своих особенностей (необходимости вложенности) должны выстраиваться гомоархически (в субъекты), а вот связи и реакции гетерархично (в объекты) по причине завязки на места.
Параметры
Для рефлексов определены такие параметры:
- Ориентир, где идёт обозначение рефлекса
- Условия, где код условия («if»)
- Расчёты, где идёт описание рефлекса
- Места, где перечисляются id мест для активации
- Вложение, подкатегории рефлексов
Для мест определены такие параметры:
- Смысл, где идёт обозначение места
- Тип, где идёт назначение места
- Связи, где перечисляются id связей для активации
- Вложение, подкатегории мест / значение
Для связей определены такие параметры:
- Импорт вложений с мест, где перечисляются id мест (с типом переменная)
- Экспорт вложений в места, где перечисляются id мест (с типом переменная)
- Пример импорта вложений с мест
- Пример экспорта вложений в места
- Реакция, где перечисляются id реакций для активации
Для реакций определены такие параметры:
1. Функция, где алгоритм
Цикл
Далее я установил необходимую последовательность активации компонентов (последовательный цикл):
- Реакции активируют рефлексы
- Рефлексы активируют места
- На местах активируются связи
- Связи активируют реакции
Итогом получился замкнутый на себя проект, вмещая в себя все необходимые и важные по своей функциональности компоненты, обеспечивающие адекватную реакцию на внешнее событие (запрос).
Пример
Эскиз примера (стрелки обозначают влияние / активацию):
Далее по теме: Трансформер-интерфейс на JS посредством CSDR.
Комментарии (39)
DOC_tr
02.11.2019 23:19+1Статья, если честно, какая-то вода. Но код из примера… Это что-то с чем-то. Это единственное что сподвигло меня написать данный комментарий.
1.$GLOBALS
Кто-то использует их в 2019? Да даже если откатиться лет на 5-6 назад, то даже тогда использование глобалов уже было плохой практикой.
2. Ключи ассоциатвиного массива написаны кириллицей?
3. Ключи массива строки и начинаются с 1?
4.
function &($place_id){
Интересная конструкция
5.
$link = &$GLOBALS['Места']; $link = &$link['Вложение'];
Это ссылка на ссылку?
6.
if(eval('return ' . $goal_row['Условия'] . ';') == true){
Ну тут мне даже сказать нечего…
7.
foreach($goal_row['Места'] as $place_id){ /*получаем связи*/ $communications = $function_link_place_by_id($place_id)['Связи']; /*если есть связи*/ if($communications){ /*обходим связи*/ foreach($communications as $communication_id){ /*если есть реакции*/ if($GLOBALS['Связи'][$communication_id]['Реакция']){ /*обходим реакции*/ foreach($GLOBALS['Связи'][$communication_id]['Реакция'] as $reaction_id){
Больше foreach богу foreach
8.
/*результат*/ return null;
Результат null. окей
В целом, код очень похож на тот, который пытался продвинуть на хабре пользователь coresky, но что-то у него не задалось. Думаю что и вас ждет та же судьба
it-architector Автор
03.11.2019 02:04-2Для меня судьба благосклонна, не волнуйтесь, я в хорошем пушке, можно не париться о зарабатывании денег. ))))) Проект который я задумал реализован в виде работающего кода. :) Без каких либо классов.) Код целостен и самодостаточен.))) В описании же я сделал «воду» дабы наглядно было видно как создавать целостный проект «от» и «до».)))) Спасибо вам большое, что глянули код!
roscomtheend
05.11.2019 09:38я в хорошем пушке
Посмотрите внимательней — это плесень (иногда она выглядит как пушок).
реализован в виде работающего кода
Говнокода, он может "работать", но лишь потому, что никому не нужен. Вы, случаем, "драйвер базы данных" не писали? Уж очень самомнение и запах от кода похожи.
dukei
02.11.2019 23:34it-architector ещё очень молодой IT архитектор, видимо. Стремления прекрасны, но реализация ужасна. Но ничего, с опытом придет. Но пока все же лучше ориентироваться на существующие фреймворки. Изучить, так сказать, врага, несмотря на то, что у всех присутствует фатальный недостаток.
it-architector Автор
03.11.2019 02:06Старый я, ибо кто ещё решится на такое)))) Для меня же ужас это классы, создающие наркоманские недопроекты))))))) И не бойтесь, я не конкурент)))) У меня много чего есть, за просто так)))) Только жить и прокачивать себя остаётся)))
roscomtheend
05.11.2019 11:27Если он пойдёт на работу на какой-нибудь умирающий завод программирующим эникеем, то ничего не придёт (мудрость приходит с возрастом, но в таком случае возраст придёт с маразмом). Была история "создателя драйвера баз данных" (сколь помню — в реале пародию на in-memory-database), где делались экранные формы, а по ним — структура базы, он кричал что "его ПО работает у Биллайн!" (на самом деле Би_лл_айн, судя по всему — система учёта телефонии или чего-то подобного уровня предприятия, где пара девочек что-то набивала в его поделии, могли бы и ёксель использовать с не меньшим успехом). Поработав там достаточно лет, став гениальнейшим (ибо единственным в том болоте) разработчиком, он отправился покорять sql.ru, где закономерно стал посмешищем и лишь благодаря своей упёртости (и упоротости) стал известен (тема выросла под сотню страниц, где он пытался доказать что все дураки и не понимают его творения). Были там и другие, типа создателя "самого короткого языка программирования", тоже уверенного в исключительной полезности своего творения и тоже считал себя непонятым гением. В реале были и "архитекторы", которые что-то неправильно сделали, совета в их междусобойчике спросить было не у кого и это worst practice они норовили тащить в другие проекты (на своём "авторитете", базирующемся на возрасте, при таких вводных оставалось или послать такого "архитектора", или такой проект — научиться они уже не способны).
mmasiukevich
03.11.2019 02:43таких архитекторов надо в макдональдс на работу ссылать
NiceDay
03.11.2019 06:08За всё время работы программистом, я сталкивался с различными задачами по доработке сайтов.
И, я так понимаю, это было единственным вашим занятием за все время работы программистом.
И отметил одно:
функций много,
Да, потому что они решают свои, определенные задачи.
по разных файлам разбросанно
Вы считаете, что в вашем примере, где всё засунуто в один файл, стало гораздо лучше?
общей картины пространства имён не видно
У вас вообще общей картины не видно, видна лапша.
Знаете, пытаться разобраться в таком равноценно попытке найти два конца одной спагетти-макаронины в тарелке, полной спагетти. Теоретически, конечно, можно, но в здравом уме этим заниматься никто не будет.
где то (например в yii) нужно ещё инициировать проект, чтобы через phpmyadmin увидеть актуальные таблицы…
Как ваш пример решает эту «проблему»? Какую проблему вообще решает ваш пример?
Неструктурированно пространство имён
Вы пошли просто: нет пространств имен — нет проблем, верно?
PHP-коды по методу «ООП на классах»
Решают очень большое количество проблем.
Например, вот эту проблему:
RedComrade
03.11.2019 10:30Если я не ошибаюсь, то автор публикует повторно свою работу, в прошлый раз она была менее подготовлена, и вызвала такой холивар что ее удалили, еще мне помнится что автор был ярым противником ООП, и как мне показалось подход не состоятелен для более менее крупных проектов, а проблемы которые испытывает автор решаются на уровне написания документации по проекту
ButscH
03.11.2019 11:09Привет it-architector. Я сейчас нахожусь в поиске фреймворка под свой новый проект и твой мне показался достаточно перспективным, но хотелось бы уточнить несколько деталей:
1. В новом проекте у нас будет около 20 «контроллеров» (Не совсем погрузился в твою терминологию, поэтому сложно понять куда их отнести). В какую часть мне отнести функционал контроллеров? А в какую шаблоны? Поддерживает ли твой фреймворк шаблонизаторы (Заказчик требует, говорит верстальщику так проще)?
2. Буду признателен, если покажешь пример с роутингом. У меня будет следующий список страниц: Список продуктов, Страница продукта, Корзина, Оформление заказа, Динамические страницы ну и какое то API для партнеров
3. В ТЗ указано, что при заполнении формы нужно валидировать данные, проверять корректность email адреса, телефона, заполненность определенных полей
4. У нас планируется оплата через платежные сервисы, куда этот функционал мне отнести?
Сколько будет стоить разработка такого проекта? Сейчас собираю команду
Ну а так, в целом… Ты в 1С раньше не программировал?
P.S. Я попробовал создать простенькое приложение по твоей схеме и вроде все нравится, но вот постоянно допускаю ошибки в ключах массивов и постоянно нужно искать где я их допустил. Есть какая то методика решения?it-architector Автор
03.11.2019 11:37Доброго ButscH! Это всего лишь архитектура. :) До фреймворка у меня ещё далеко, то что beta — то не то, мне нужна была наглядность.
В какую часть мне отнести функционал контроллеров?
Весь контроль задан рефлексами, где содержится вся условность на внешний запрос.
Буду признателен, если покажешь пример с роутингом.
Кратко это так (это всё перейдёт в массив рефлексии):
if(isset($_GET['page'])){ //рефлекс ядро
if($_GET['page']=='forum'){ //рефлекс форум
if($_GET['type']=='topics'){ //рефлекс топики
}
if($_GET['type']=='topic' and isset($_GET['id'])){ //рефлекс топик один
}
}
}
В ТЗ указано, что при заполнении формы нужно валидировать данные, проверять корректность email адреса, телефона, заполненность определенных полей
Вы скорее просмотрели beta версию, там я сделал проверку через jquery.validate.js, но тот переходный вариант, который будет уничтожен из за временности. :) CSDR-интерфейс ещё не создал, согласовать бы до конца вышеописанную архитектуру. :)
У нас планируется оплата через платежные сервисы, куда этот функционал мне отнести?
Так же создавать рефлексию, с определенным условием на перехват isset($_GET['pay']) and isset($_GET['type'])... и т.п. до финиша.
На рефлексии делать роли: платежные сервисы, определение типа, получить деньги, отправить деньги, проверить статус, создать отчёт платежа, выдать отчёт пользователю… как спланируется. :) Создать необходимые переменные.
И дальше на каждую роль цеплять связь-реакцию (алгоритм).
Я попробовал создать простенькое приложение по твоей схеме и вроде все нравится, но вот постоянно допускаю ошибки в ключах массивов и постоянно нужно искать где я их допустил. Есть какая то методика решения?
По идее нужен будет интерфейс, который автоматизирует всё необходимое (создаст ключи, даст ограниченный выбор), что сделает программирование связанным и более просматриваемым (как будто в базе данных mysql схему собираешь, помните?).
По поводу 1С умолчу. :)
Rukis
03.11.2019 12:02it-architector я правильно понимаю, что это не первый ваш хабр аккаунт и не первая ваша архитектурная идея не принимаемая другими? Просто уже были статьи с вещами подобного уровня с изобретением странных терминов и с подобным отношением автора к традиционным подходам.
Вообще в самой по себе новой, не обычной идеи ничего плохого нет, даже если она очень странная, это не плохо, просто возможно у вас не хватает опыта или, возможно, у вас просто совершенно другое восприятие и образ мышления.
Удивляет, что вы не понимаете и не принимаете критики и доводов сообщества. Это примерно как если вы вдруг обнаружили, что отказ от привычных знаков пунктуации в пользу цветовой индикации не только экономит бумагу, но и конкретно вам кажется намного удобнее. Рассказали об этом людям, а они, зашоренные глупцы, не смогли оценить всей прелести нового подхода.
Вы же понимаете, что устоявшиеся подходы имеют причины, что они эволюционировали, проверялись, сравнивались, совершенствовались и всё это делалось многократно, огромным количеством не глупых людей? Ведь понимаете, что нет 100% универсальных архитектурных решений, что всегда есть некоторый компромисс и, что различных подходов требуют не только разные по своей сути задачи, но и, порой, одинаковые задачи на разных этапах, в разных обстоятельствах?
Вы противопоставляете свой подход php фреймворкам заточенным на покрытие большого числа типичных кейсов в разработке веб сайтов и сервисов. Но иллюстрируете это все таким примером кода, который к типичным для веб задачам отношения не имеет и никаких проблем не решает. К тому же наполнен практиками, которые были признаны плохими не на пустом месте, а ввиду конкретных проблем.
Так вы однозначно обречены на непонимание, даже если все ошибаются и ваши идеи лучше того, чем пользуются остальные.
Но это можно легко исправить. В по первых надо обозначить область применения, для каких задач ваш подход предназначен, а для каких его лучше не применять? Во вторых, стоит привести типичную задачу, реализацию какого то простого сайта, веб апи, сервиса, для чего ваше решение лучше всего годиться.
Покажите, как предлагается работать с запросами, ответами, маршрутизацией, как будет происходить работа с БД, с файлами, кешем, как будут обрабатываться ошибки и тд. Сравните наглядно общепринятый и ваш подход, продемонстрируйте на конкретных примерах какие проблемы имеет первый (это важно, пока все аргументы были «мне не нравится/удобно/понятно») и как их решает второй.
Зная область применения и сравнивая подходы на конкретных задачах можно будет конструктивно что то заявлять или опровергать. Пока вы только лишь продемонстрировали экзотичность ваших вкусов, а остальные в ответ поморщились.it-architector Автор
03.11.2019 12:27Rukis, добротных дней! :)
Вы противопоставляете свой подход php фреймворкам заточенным на покрытие большого числа типичных кейсов в разработке веб сайтов и сервисов.
Но это можно легко исправить.
Согласующий подход! :)
Во по первых надо обозначить область применения, для каких задач ваш подход предназначен, а для каких его лучше не применять?
Спасибо! Кратко: это подход к программированию. Не фреймворк. :)
Во вторых, стоит привести типичную задачу, реализацию какого то простого сайта, веб апи, сервиса, для чего ваше решение лучше всего годиться.
Спасибо вам и за это! Пока годится как: сопровождение построения проекта ядро на php. Какого масштаба — нужно ещё вычислять, а это время, дожить бы. :) Но подход с таким программированием уже работает, малюсенький пример привёл.
Покажите, как предлагается работать с запросами, ответами, маршрутизацией, как будет происходить работа с БД, с файлами, кешем, как будут обрабатываться ошибки и тд.
Дожить бы до такого… я ещё интерфейс то не проработал! Фреймворка нет, и пока в планах его нет, коли не завершу интерфейс. Наверно кто то ошибочно понял что я пропагандирую фреймворк… уверяю, я сомневаюсь что успею его сделать и кто то сможет продолжить моё дело, после.))))Rukis
03.11.2019 13:17Ну хорошо, вроде как рахсодится логикой статьи, но да ладно. В таком случае, если это общий подход, то все равно ведь можно привести задачи и их решения в двух экземплярах, одно согласующееся с принятыми практиками, второе — ваш подход. И таким образом перейти от описания личных предпочтений к демонстрации конкретных преимуществ и решаемых проблем.
Samouvazhektra
03.11.2019 14:23Судя по ответу выше, автор толком никаких других фреймворков не осилил, кроме как на уровне костыльных правок, поэтому и занялся изобретением велосипедов (Если я жестоко ошибаюсь, то пруфы конечно предоставят)
Очень рекомендую автору посмотреть для начала вдумчиво посмотреть хотябы
https://elisdn.ru/blog/113/psr7-framework-http
GreedyIvan
03.11.2019 12:07-1Фреймворк — огонь. Планируется ли к нему написать кодогенератор, чтобы можно было сосредоточиться исключительно на бизнес-логике, и свести написание обслуживающих конструкций к нулю?
Что с тестируемостью? Насколько легко натянуть на данных фреймворк декларативный подход в тестах? С тем же минимумом служебных конструкций. Только описания.
it-architector Автор
03.11.2019 12:40-1GreedyIvan, спасибо!
Планируется ли к нему написать кодогенератор, чтобы можно было сосредоточиться исключительно на бизнес-логике, и свести написание обслуживающих конструкций к нулю?
Ну так и планировал, что каждый в чём преуспевает — тем и занимается. В нём 4 направления. Каждому по способностям, трудоголикам — алгоритмы писать, ленивым котикам — рефлексию организовывать, фантазёрам — роли проектировать, ну а жирафам — связи делать. А с помощью интерфейса (если его написать), который всё автоматизирует и предоставит в удобном варианте — написание проекта будет как например постройка интерфейса с помощью шаблонов и ввода текста (или кода алгоритма).
Фреймворк — огонь.
Это не фреймворк. Это подход к построению проекта, притом только ядра. :) Из него в будущем возможно выстроить фреймворк, но я пока ещё не осилил интерфейс.
Что с тестируемостью?
Ну если приделать к написанию проекта интерфейс работы над проектом, то можно например написав реакцию (алгоритм) тут же эту реакцию и протестировать (нажав кнопку теста), или какой либо участок, забив при этом данные для теста. То есть проект уже сам себя может контролировать, полностью. :) И уже если какой сбой, то он в виде: претензия к рефлексии, претензия к месту, претензия к связи, претензия к реакции.
index0h
03.11.2019 14:14Это не фреймворк. Это подход к построению проекта, притом только ядра. :) Из него в будущем возможно выстроить фреймворк, но я пока ещё не осилил интерфейс.
Вы и не осилите. Объекты реального мира, которые моделируются слишком вариативны, что бы их можно было разделить на 4 категории с конкретными интерфейсами.
loki82
03.11.2019 13:52Всегда думал это проблема самого php. Ан нет. Оказывается вот такие практики портят отношение к языку. Одни только вложенности циклов чего стоят. Как это читать? Совсем не понятно где искать модели, как согласовать со сторонней системой?
index0h
03.11.2019 14:10Автор, то что вы хотите продать как свое how now называется "декларативное программирование". Задача, которую вы поставили перед собой на самом деле — это снижение сложности. Хотите вы того, или нет, для этой задачи нет серебрянной пули. Ваше решение только выносит сложность на уровень выше, но ни как не помогает в целом.
Судя по коду, примера — опыта даже на юниора у вас нет, а ваша мотивация написания подобного — это демонстрация вашего этапа (пик глупости) в изучении программирования по Даннингу-Крюгеру.
Не волнуйтесь, многие через это проходят, это нормально.
a1ex322
03.11.2019 19:37Проблема, видимо, в том, что автору "религия не позволяет" написать конструкцию вида $service->method(), а в php насколько мне известно нет других вариантов разбить проект на модули.
michael_vostrikov
04.11.2019 08:09
$user_id = $parameters['Идентификатор пользователя']; $session = md5('formation-'.$user_id.'-'.$_SERVER['SERVER_ADDR']); return $session;
Дыра в безопасности.
index0h
04.11.2019 14:09+1it-architector http://www.angely-sveta.ru/russian/default_ru.htm — это случайно не ваша поделка?
ZaEzzz
Какой-то гомеопатический несогласованный подход… Лучше закрыть публикацию.
it-architector Автор
Завидуйте молча.)))))))) Мхаха))))
Mylistryx
По стилю кода\общения\социального поведения\да и по нику вы мне очень напоминаете моего тезку из соседнего дома, который знает два мнения, моё и неправильное. Когда используя его же подход, ему пытаешься что-то объяснить на примере говна и мух, то упираешься в стену непонимания и отрицания. Здесь я вижу то же самое.
Уважаемый автор, если вы действительно хотите когда нибудь в перспективе работать с ноутбуком попивая коктейль и полеживая на шезлонге на пляже в теплых странах, то научитесь хотя бы понимать, что то, что вы не смогли осилить ввиду своего юношеского максимализма, либо скудоумия — не значит, что ваше мнение есть неоспоримая истина.
P.S. Сергей Н., может вам вернуться обратно в охранники/контролеры магазинов? Там вы хоть не так выделялись на общем фоне.
P.P.S. Почему я так уверен, что это Сергей Н.? Да не может быть во вселенной второго такого мудака…