ExBB Community » Разное » О жизни » Размышлизмы о движке

Страниц (5): « 1 2 [3] 4 5 »
 

31. Flat - 25 сентября 2018 — 09:14 - перейти к сообщению
Для тех кому интересно прочитайте статью "Моё разочарование в софте" на хабре:здесь
Проблема в том, что фреймворки с каждым днём становятся всё сложней, глючней, и медленней. Причину я вижу именно в концепции опп, которая на аппаратном уровне задействует механизмы раздувающие код до ужасающих размеров, хотя программисту это и не видно, поэтому всё как бы нормально(для программиста). А для потребителя наступает полный ужас. Вы хотите жить в этом ужасе? Я лично - нет. Вам может лично не нужен движок на 100% свободный от ооп, потому что вам кажется что ооп лично вам что-то такое предоставит.. Но предоставить оно может только тормоза и ещё раз тормоза, и в итоге ваш скрипт просто отключат от сервера на котором он крутится по исчерпании лимита времени его работы.. Зато это может понадобится другим, которым важна простота, стабильность в работе и скорость, а этого ой как недостаёт в современном мире. Пускай таких как я одиночек считают ретроградами, но я уверен - за нами будущее, ибо весь этот софт напичканный непонятно чем, временным, вскоре исчезнет потому-что идёт тупиковым путём, а вещи сделанные с прицелом на будущее, "не модные" останутся.
32. NordWest - 25 сентября 2018 — 13:59 - перейти к сообщению
Flat пишет:
Что касается темплейтов, то я ещё в поиске, хотя сильно соблазняет предложенный вариант, из-за возможности изменений сторонними функциями, и похоже, что это преимущество перевесит все сомнения.
Если я правильно понял вашу идею, то вы разбиваете шаблон на блоки, которые загружаете в память в виде текстового массива. Затем движок имеет возможность манипулировать этими блоками как пожелает программист.

Идея в принципе любопытная, но меня смущает сложность работы с подорбным шаблоном - массив имеет цифровые индексы. Если шаблон будет большого размера как отслеживать какой индекс использовать?

И ещё... представьте, что вы написали функцию, которая из предложенного вами массива формирует код и всё успешно работает. Потом вам понадобилось внести изменения в середине шаблона и нумерация строк (а следовательно и индексация массива) у вас изменится. Что в этом случае произойдет. Нужно будет полностью переиндексировать функцию вывода причем малейшая ошибка будет приводить к тому, что дизайн будет просто рассыпаться. Растерялся
33. Flat - 26 сентября 2018 — 08:38 - перейти к сообщению
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 файлы, при этом старая функция работать перестанет, а вывод пойдёт через новую. А старая пусть валяется в коде, может когда-нибудь пригодится если откатить новый мод назад.. Так что вы абсолютно правы, - менять-то придётся оба файла, а это ой как неудобно! Так что идей-ка то сыровата..
34. Flat - 27 сентября 2018 — 08:27 - перейти к сообщению
Переделал всё обратно. Действительно - так лучше. Это кстати соответствует одной из концепций MVC. Здесь также можно менять шаблоны путём переключения функций.
index файл сделал. Подключение модулей в нём работает. Подключаю тестовый модуль, в сё в порядке. Все папки с модулями, шаблонами и языками распределил, всё работает. То есть основную структуру сделал. Теперь можно спокойно заниматься наворачиванием модулей по ходу их тестируя почти готовым ядром.
35. 1Bot - 27 сентября 2018 — 09:08 - перейти к сообщению
Аспекты строительства архитектуры

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

Структурное программирование накладывает ограничение на прямую передачу управления.
Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.
Функциональное программирование накладывает ограничение на присваивание.
36. 1Bot - 27 сентября 2018 — 10:10 - перейти к сообщению
Поддержка полиморфизма дает абсолютный контроль над всеми зависимостями в исходном коде.
Это позволяет создать архитектуру со сменными модулями (плагинами), в которой модули верхнего уровня не зависят от модулей нижнего уровня.
Низкоуровневые детали не выходят за рамки модулей плагинов, которые можно развертывать и разрабатывать независимо от модулей верхнего уровня.
37. Flat - 27 сентября 2018 — 10:46 - перейти к сообщению
1Bot пишет:
Используем объектно-ориентированное программирование, а именно полиморфизм как механизм преодоления архитектурных границ.

Ну, архитектурные границы можно преодолеть и простым пространством имён, или соглашениями. ООП вводит много ненужных ограничений.
1Bot пишет:
Используем функциональное программирование для наложения ограничений на местоположение данных и порядок доступа к ним.

Концепция функционального программирования ещё довольно далека от реальной жизни. "Всё есть функция" - не правильный постулат.
1Bot пишет:
Используем структурное программирование как алгоритмическую основу для наших модулей.

Это уже ближе к реальности. Однако и оно имеет свои ограничения. Приходится постоянно изобретать новые костыли чтобы влезть в прокрустово ложе "структурности".
1Bot пишет:
Структурное программирование накладывает ограничение на прямую передачу управления.
Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.
Функциональное программирование накладывает ограничение на присваивание.

Вы слышали об автоматном программировании? Про разработки профессора, доктора технических наук, Анатолия Шалыто - https://ru.wikipedia.org/wiki/Ша...атолий_Абрамович? Он преподаёт компьютерные технологии на кафедре в ИТМО. Я читал его книгу "Автоматное программирование", а также много чего на его сайте. Также слушал его лекцию на ю-тьюбе. На мой взгляд за этим будущее. Некоторые вещи я пытаюсь делать применяя эту методологию.
1Bot пишет:
Поддержка полиморфизма дает абсолютный контроль над всеми зависимостями в исходном коде.

Полиморфизм может быть и без ООП. в php нет указателей на функции, как в си или с++, но возможно сделать нечто подобное.
1Bot пишет:
Это позволяет создать архитектуру со сменными модулями (плагинами), в которой модули верхнего уровня не зависят от модулей нижнего уровня.

Согласен. Это то, что я и хочу видеть в новом движке.
38. 1Bot - 27 сентября 2018 — 11:19 - перейти к сообщению
Автоматное проектирование для встроенных систем и систем реального времени целиком оправдано техническими ограничениями, но для других областей чрезмерно усложнена.

Например как выделить состояния форума при отправке поста пользователем или его редактировании/просмотре и т.д.?

Автоматное проектирование очень эффективно там, где используют разные типы управления объектами с учетом их состояния.

Т.е. для форума это очень притянуто.
39. 1Bot - 27 сентября 2018 — 12:26 - перейти к сообщению
Flat
К понятию класса приходишь постепенно, если много пишешь на процедурном языке.
В какой-то момент просто не захочешь писать функции, которые принимают аргументом указатель на структуру.
К понятию private приходишь, когда понимаешь, что все поля данной структуры предназначены для внутреннего пользования и объявляешь структуру уже в отдельном файле, в реализации.

Далее приходишь к понятию конструктор и деструктор.

В общем-то, если много пишешь, сам придёшь к ООП от процедурного программирования.

Но после ООП переходить на функциональное программирование - здесь уже нужна не практика, а стремление "сделать не как все".
40. Parapsixolog - 27 сентября 2018 — 19:56 - перейти к сообщению
Flat пишет:
Моё разочарование в софте" на хабре:здесь


Прочитал Flat вашу статью, и полностью вас поддерживаю. Сам постоянно удивляюсь, как можно писать так программы, жрущие ресурсы. Вот например мозила феервокс на днях сожрала у меня 7 гигов оперативки!

И такая ситуация и с другими программами. У меня такое впечатление, что программисты создают программы под лозунгом, чем больше жрёт программа, тем лучше.

Помню ещё как то писали, что производители комплектующих и компьютеров заинтересованы в тяжелом ПО, с целью стимулирования апгрейда пользователей на новинки, и типа как то стимулируют программеров на это.
41. Flat - 28 сентября 2018 — 03:04 - перейти к сообщению
1Bot пишет:
но для других областей чрезмерно усложнена.

Чем сложнее задача, тем легче её решить в автоматном стиле.
1Bot пишет:
Например как выделить состояния форума при отправке поста пользователем или его редактировании/просмотре и т.д.?

По предыдущим состояниям действий пользователя. Есть же сессии, хотя можно и без них. Можно даже вести историю действий пользователя.
1Bot пишет:
Т.е. для форума это очень притянуто.

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

В программировании постоянно твердят, что глобальные переменные зло, во всяком случае когда их слишком много. Функции жёстко на них завязаны, поэтому они не расширяемы, не могут использоваться другими компонентами системы. А от этого система начинает распухать, жиреть.. В классе то же самое: там есть свои глобальные переменные, и функции-методы, которые на них жёстко завязаны.. Просто теперь этих клеток стало очень много, - целая тюрьма.. Данные и функции-обработчики это разные звери. Данные статичны, методы динамичны. Мы взяли и поместили их в одну клетку-класс, и нам кажется, что мы достигли этим инкапсуляции. Однако инкапсуляция тем больше, чем больше других компонентов можно вставить в уже существующий класс. По моему об этом писал Скотт Мейерс в статье "Как функции, не являющиеся методами, улучшают инкапсуляцию". То есть практика показывает, что мы многое потеряли.. А тут ещё наследование.. "Проблема с ОО-языками заключается в том, что они тянут за собой всё своё окружение. Вы хотели всего лишь банан, но в результате получаете гориллу, держащую этот банан, и все джунгли в придачу." Это не я сказал, Джо Армстронг создатель языка Erlang.
Я раньше увлекался таким языком программирования как Fort. Почитывал Лео Броуди. так вот он считал ооп сырой идеей и больше склонялся к компонентной модели. Программа делится на маленькие компоненты, каждый из которых выполняет свою работу. Более крупные компоненты пользуются услугами более мелких. Так растёт дерево программы: от корней к кроне, от низа до верха. Принцип взаимосотрудничества компонентов. А в ООП каждый класс воюет с другим классом, как буд-то они какие-то враги друг другу. Но они же представляют из себя одну и туже программу! Это единый организм, каждый орган которого выполняет свою функцию, и все вместе образуют слаженную систему. А в ООП система состоит из отдельных организмов, враждующих с друг другом и общающихся с друг другом посредством "сообщений".. Один обьект посылает сообщение другому с просьбой: вымой-ка посуду, дружище, а другой в этот момент занят: я читаю газету, отстань от меня, попозже как-нибудь вымою.. Это вот такие сейчас программы. Там теперь не отдают чёткие приказы, что делать, а теперь любезно просят сторонний обьект соблаговолить отложить свои дела и заняться этим..
Parapsixolog пишет:
Прочитал Flat вашу статью, и полностью вас поддерживаю

Ну, эту статью не я писал, просто привёл ссылку на отличное видение проблемы.
Parapsixolog пишет:
Вот например мозила феервокс на днях сожрала у меня 7 гигов оперативки!

Так практически во всех браузерах. Программисты не заморачиваясь просто запускают на каждую вкладку по отдельному экземпляру браузера, который работает в своём процессе-потоке, отсюда разбухание. Это в корне неверно, но так делают для собственного удобства, быстроты программирования. Страдает потребитель..
42. Flat - 28 сентября 2018 — 04:17 - перейти к сообщению
Также интересен подход, который исповедует новая парадигма дата-ориентированного программирования, то есть ориентированного на данные, которые первичны в её понимании. http://gamesfromwithin.com/data-oriented-design
Данные это знание о том что существует в мире, а не просто сами данные. В движке нам нужно знать не только о том, что существует информация о пользователе, но и о том, что существуют сами функции движка. Нужен некий реестр всех функций в системе, то бишь знание о их существовании.. Тогда возможно менять их только через этот реестр. Нужен реестр модулей системы, чтобы их добавлять, подменять или удалять.. Всё группируется вокруг данных, данные это - всё. Например функция вывода главной страницы обращается к реестру блоков главной страницы и выводит их в соответствии этому списку. В список можно добавить блок, можно его удалить, можно перетасовать блоки в реестре и выводить их в другом порядке. Таким образом можно легко, к примеру, добавить рекламный блок или что-либо другое.. Таким образом система становится "умнее" так как "знает" про себя всё необходимое..
43. 1Bot - 28 сентября 2018 — 19:04 - перейти к сообщению
Flat ,
Система вполне может сама о себе знать.

PHP 5 включает в себя полноценный Reflection API, который предоставляет возможность проводить реверс-инжиниринг классов, интерфейсов, функций, методов и модулей.

Кроме того, Reflection API позволяет получать doc-блоки комментариев функций, классов и методов.
44. Flat - 29 сентября 2018 — 12:06 - перейти к сообщению
1Bot пишет:
Система вполне может сама о себе знать.

Под системой я подразумевал движок форума, а не php фреймворк. То есть движок должен сам о себе всё знать, и если что - сам себя чинить!
45. Flat - 29 сентября 2018 — 13:35 - перейти к сообщению
То есть в движке должна существовать некая имунная система самовосстановления и самолечению, некий контролёр здоровья..

Яндекс.Метрика   

Powered by ExBB
[Script Execution time: 0.0279]     [ ]