| Flat |
Отправлено: 25 сентября 2018 — 09:14 
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Для тех кому интересно прочитайте статью "Моё разочарование в софте" на хабре:здесь
Проблема в том, что фреймворки с каждым днём становятся всё сложней, глючней, и медленней. Причину я вижу именно в концепции опп, которая на аппаратном уровне задействует механизмы раздувающие код до ужасающих размеров, хотя программисту это и не видно, поэтому всё как бы нормально(для программиста). А для потребителя наступает полный ужас. Вы хотите жить в этом ужасе? Я лично - нет. Вам может лично не нужен движок на 100% свободный от ооп, потому что вам кажется что ооп лично вам что-то такое предоставит.. Но предоставить оно может только тормоза и ещё раз тормоза, и в итоге ваш скрипт просто отключат от сервера на котором он крутится по исчерпании лимита времени его работы.. Зато это может понадобится другим, которым важна простота, стабильность в работе и скорость, а этого ой как недостаёт в современном мире. Пускай таких как я одиночек считают ретроградами, но я уверен - за нами будущее, ибо весь этот софт напичканный непонятно чем, временным, вскоре исчезнет потому-что идёт тупиковым путём, а вещи сделанные с прицелом на будущее, "не модные" останутся.(Отредактировано автором: 25 сентября 2018 — 09:26) |
| |
|
|
Отправлено: 25 сентября 2018 — 13:59
|
Покинул форум
Сообщений всего: 0
Дата рег-ции: N/A
Репутация: 0
|
Flat пишет:Что касается темплейтов, то я ещё в поиске, хотя сильно соблазняет предложенный вариант, из-за возможности изменений сторонними функциями, и похоже, что это преимущество перевесит все сомнения. Если я правильно понял вашу идею, то вы разбиваете шаблон на блоки, которые загружаете в память в виде текстового массива. Затем движок имеет возможность манипулировать этими блоками как пожелает программист.
Идея в принципе любопытная, но меня смущает сложность работы с подорбным шаблоном - массив имеет цифровые индексы. Если шаблон будет большого размера как отслеживать какой индекс использовать?
И ещё... представьте, что вы написали функцию, которая из предложенного вами массива формирует код и всё успешно работает. Потом вам понадобилось внести изменения в середине шаблона и нумерация строк (а следовательно и индексация массива) у вас изменится. Что в этом случае произойдет. Нужно будет полностью переиндексировать функцию вывода причем малейшая ошибка будет приводить к тому, что дизайн будет просто рассыпаться.  |
| |
|
| Flat |
Отправлено: 26 сентября 2018 — 08:38
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
NordWest пишет:Если я правильно понял вашу идею, то вы разбиваете шаблон на блоки, которые загружаете в память в виде текстового массива. Затем движок имеет возможность манипулировать этими блоками как пожелает программист.
Всё верно.
NordWest пишет:И ещё... представьте, что вы написали функцию, которая из предложенного вами массива формирует код и всё успешно работает. Потом вам понадобилось внести изменения в середине шаблона и нумерация строк (а следовательно и индексация массива) у вас изменится. Что в этом случае произойдет. Нужно будет полностью переиндексировать функцию вывода причем малейшая ошибка будет приводить к тому, что дизайн будет просто рассыпаться.
Я и сам уже думал об этом..
Первоначальный вариант, который я затем переделал на предложенный, был похож на темплейты из форумного движка SMF. Там они реализованы в виде php-шных функций. Вот пример первоначального(первого) варианта:
CODE:function exbb_showLogoStrip()
{
global $Config, $ContentBuf, $Skin;
$ContentBuf.='<table width="100%" id="logostrip" cellspacing="0" cellpadding="0"><tr><td><a href="index.php" title="'.$Config[1].'"><img src="./templates/'.$Skin.'/im/logo.gif" alt="'.$Config[1].'" width="207" height="52" border="0" /></a></td><td valign="bottom" align="right"><a href="index.php" style="margin-right:20px;color:#ffffff">'.$Config[1].'</a></td></tr></table>';
}
Так как вставить что-либо в такой шаблон затруднительно, то я пришёл к вышеозвученному решению в виде функции:
CODE:function exbb_showLogoStrip()
{
global $TemplatesPath, $Config, $ContentBuf, $Skin;
$tpl=file($TemplatesPath.$Skin.'/logostrip.html');
$ContentBuf.=$tpl[0].$Config[1].$tpl[1].$Skin.$tpl[2].$Config[1].$tpl[3].$Config[1].$tpl[4];
}
и отдельного файла шаблона, который можно скачать, изменить, и уже изменённый загрузить обратно в файл.
Вроде бы всё в порядке? Однако меня терзают такие же сомнения, которые терзают и вас.. Действительно, эти оба файла жёстко связаны с друг другом, и любой их разрыв кажется неправильным.. Но менять шаблоны ведь надо? Недавний случай с кнопкой показал это..
Единственный вариант в этом случае менять всю функцию первого варианта на другую через config файлы, при этом старая функция работать перестанет, а вывод пойдёт через новую. А старая пусть валяется в коде, может когда-нибудь пригодится если откатить новый мод назад.. Так что вы абсолютно правы, - менять-то придётся оба файла, а это ой как неудобно! Так что идей-ка то сыровата..(Отредактировано автором: 26 сентября 2018 — 08:48) |
| |
|
| Flat |
Отправлено: 27 сентября 2018 — 10:46
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет:Используем объектно-ориентированное программирование, а именно полиморфизм как механизм преодоления архитектурных границ.
Ну, архитектурные границы можно преодолеть и простым пространством имён, или соглашениями. ООП вводит много ненужных ограничений.
1Bot пишет:Используем функциональное программирование для наложения ограничений на местоположение данных и порядок доступа к ним.
Концепция функционального программирования ещё довольно далека от реальной жизни. "Всё есть функция" - не правильный постулат.
1Bot пишет:Используем структурное программирование как алгоритмическую основу для наших модулей.
Это уже ближе к реальности. Однако и оно имеет свои ограничения. Приходится постоянно изобретать новые костыли чтобы влезть в прокрустово ложе "структурности".
1Bot пишет:Структурное программирование накладывает ограничение на прямую передачу управления.
Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.
Функциональное программирование накладывает ограничение на присваивание.
Вы слышали об автоматном программировании? Про разработки профессора, доктора технических наук, Анатолия Шалыто - https://ru.wikipedia.org/wiki/Ша...атолий_Абрамович? Он преподаёт компьютерные технологии на кафедре в ИТМО. Я читал его книгу "Автоматное программирование", а также много чего на его сайте. Также слушал его лекцию на ю-тьюбе. На мой взгляд за этим будущее. Некоторые вещи я пытаюсь делать применяя эту методологию.
1Bot пишет:Поддержка полиморфизма дает абсолютный контроль над всеми зависимостями в исходном коде.
Полиморфизм может быть и без ООП. в php нет указателей на функции, как в си или с++, но возможно сделать нечто подобное.
1Bot пишет:Это позволяет создать архитектуру со сменными модулями (плагинами), в которой модули верхнего уровня не зависят от модулей нижнего уровня.
Согласен. Это то, что я и хочу видеть в новом движке.(Отредактировано автором: 27 сентября 2018 — 11:00) |
| |
|
| Flat |
Отправлено: 28 сентября 2018 — 03:04
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет:но для других областей чрезмерно усложнена.
Чем сложнее задача, тем легче её решить в автоматном стиле.
1Bot пишет:Например как выделить состояния форума при отправке поста пользователем или его редактировании/просмотре и т.д.?
По предыдущим состояниям действий пользователя. Есть же сессии, хотя можно и без них. Можно даже вести историю действий пользователя.
1Bot пишет:Т.е. для форума это очень притянуто.
В некоторых моментах не обойтись. Например в режиме регистрации пользователя необходимо отслеживать его ввод для того, чтобы при ошибке ввода какого-то поля, отправлять пользователю новую форму с уже введёнными им правильными полями, чтобы пользователю не нужно было повторно вводить правильно-заполненные поля. Кстати, в данном движке это отсутствует. Это легко сделать в том же структурном стиле? Проще применить автомат, который позволяет отследить все состояния регистрации, в том числе откуда юзер пришёл на страницу регистрации. Также и по другим формам ввода.
1Bot пишет:К понятию класса приходишь постепенно, если много пишешь на процедурном языке.
В программировании постоянно твердят, что глобальные переменные зло, во всяком случае когда их слишком много. Функции жёстко на них завязаны, поэтому они не расширяемы, не могут использоваться другими компонентами системы. А от этого система начинает распухать, жиреть.. В классе то же самое: там есть свои глобальные переменные, и функции-методы, которые на них жёстко завязаны.. Просто теперь этих клеток стало очень много, - целая тюрьма.. Данные и функции-обработчики это разные звери. Данные статичны, методы динамичны. Мы взяли и поместили их в одну клетку-класс, и нам кажется, что мы достигли этим инкапсуляции. Однако инкапсуляция тем больше, чем больше других компонентов можно вставить в уже существующий класс. По моему об этом писал Скотт Мейерс в статье "Как функции, не являющиеся методами, улучшают инкапсуляцию". То есть практика показывает, что мы многое потеряли.. А тут ещё наследование.. "Проблема с ОО-языками заключается в том, что они тянут за собой всё своё окружение. Вы хотели всего лишь банан, но в результате получаете гориллу, держащую этот банан, и все джунгли в придачу." Это не я сказал, Джо Армстронг создатель языка Erlang.
Я раньше увлекался таким языком программирования как Fort. Почитывал Лео Броуди. так вот он считал ооп сырой идеей и больше склонялся к компонентной модели. Программа делится на маленькие компоненты, каждый из которых выполняет свою работу. Более крупные компоненты пользуются услугами более мелких. Так растёт дерево программы: от корней к кроне, от низа до верха. Принцип взаимосотрудничества компонентов. А в ООП каждый класс воюет с другим классом, как буд-то они какие-то враги друг другу. Но они же представляют из себя одну и туже программу! Это единый организм, каждый орган которого выполняет свою функцию, и все вместе образуют слаженную систему. А в ООП система состоит из отдельных организмов, враждующих с друг другом и общающихся с друг другом посредством "сообщений".. Один обьект посылает сообщение другому с просьбой: вымой-ка посуду, дружище, а другой в этот момент занят: я читаю газету, отстань от меня, попозже как-нибудь вымою.. Это вот такие сейчас программы. Там теперь не отдают чёткие приказы, что делать, а теперь любезно просят сторонний обьект соблаговолить отложить свои дела и заняться этим..
Parapsixolog пишет:Прочитал Flat вашу статью, и полностью вас поддерживаю
Ну, эту статью не я писал, просто привёл ссылку на отличное видение проблемы.
Parapsixolog пишет:Вот например мозила феервокс на днях сожрала у меня 7 гигов оперативки!
Так практически во всех браузерах. Программисты не заморачиваясь просто запускают на каждую вкладку по отдельному экземпляру браузера, который работает в своём процессе-потоке, отсюда разбухание. Это в корне неверно, но так делают для собственного удобства, быстроты программирования. Страдает потребитель..(Отредактировано автором: 28 сентября 2018 — 03:15) |
| |
|
| Flat |
Отправлено: 28 сентября 2018 — 04:17
|
Full Member
Покинул форум
Сообщений всего: 187
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Также интересен подход, который исповедует новая парадигма дата-ориентированного программирования, то есть ориентированного на данные, которые первичны в её понимании. http://gamesfromwithin.com/data-oriented-design
Данные это знание о том что существует в мире, а не просто сами данные. В движке нам нужно знать не только о том, что существует информация о пользователе, но и о том, что существуют сами функции движка. Нужен некий реестр всех функций в системе, то бишь знание о их существовании.. Тогда возможно менять их только через этот реестр. Нужен реестр модулей системы, чтобы их добавлять, подменять или удалять.. Всё группируется вокруг данных, данные это - всё. Например функция вывода главной страницы обращается к реестру блоков главной страницы и выводит их в соответствии этому списку. В список можно добавить блок, можно его удалить, можно перетасовать блоки в реестре и выводить их в другом порядке. Таким образом можно легко, к примеру, добавить рекламный блок или что-либо другое.. Таким образом система становится "умнее" так как "знает" про себя всё необходимое.. |
| |
|
|
Сайт проекта ExBB
Чат на форуме
Помощь
Поиск
BanList
Без описания
