На тему Дерево-Ориентированного программирования я планирую написать несколько статей с постепенным усложнением материала. Это первая статья из серии, она предназначена для начинающих. Хотя надеюсь, что польза ею будет причинена даже опытным программистам.
В программировании есть два способа реализации объектов — наследование и композиция. Про наследование вам много и подробно расскажут в каждом учебнике, но когда речь заходит за композицию, то оказывается, что ничего, подобного объектно-ориентированному программированию в этом направлении не существует.
В сущности, композиция, это составление объекта из других, каждый из которых также состоит из других объектов. И, если задумаетесь, то обнаружите, что удивительным образом по-другому то и быть не может. Злые языки поговаривают, что бывают всякие очарованные кварки и иже с ними бозоны с лептонами, которые уже не делятся. Но это неточно.
Что получится, если попытаться описать составной объект? Как ни старайся, ничего другого, кроме древовидной структуры у вас не получится. Отсюда первый принцип:
Чтобы описать древовидную структуру нужно использовать древовидную структуру.
© Ваш КО
Поскольку любая программа — это всегда составной объект, то все программисты занимаются построением дерева объектов. И, если вам скажут, что Дерево Ориентированного программирования не существует, ответствуйте:
— Несчастные, за деревьями леса не видите! Только оно и существует!
Это и есть второй принцип:
Существует программирование только Дерево Ориентированное. Но бывает оно осознанное, а бывает нет.
С осознанием этих, казалось бы, очевидностей, возникает вопрос:
— А оно нам надо?
— Да-да, а не пошло бы это дерево лесом!?
И тут вот какие соображения имеются:
Все эти сложные объектно-ориентированные, дженерик-типизированные, солид-кисс-блабла-концептуализированные парадигмы созданы с единственной целью — упростить программирование. Дерево-Ориентированное программирование дает ещё одну степень ограничения сложности.
Чем проще программирование, тем сложнее программы мы можем создавать, тем больше денег зарабатывать, чего уж там стесняться этого факта.
Принципы Дерево-Ориентированного программирования просты и понятны, кроме первых двух. Но для начала, давайте определимся, что такое дерево объектов в нашем понимании, и как мы его можем построить в простейшем виде.
Итак, деревом объектов мы будем называть группу иерархически взаимосвязанных объектов.
Дерево объектов состоит из узлов — программных объектов разных классов, поддерживающих иерархическую функциональность.
Таким образом, например, документ XML или JSON мы не будем называть деревом объектов, это будет дерево данных. Дерево (Map), полученное в результате их стандартного парсинга, также будем называть деревом данных, поскольку составляющие его объекты не поддерживают иерархические связи.
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел, а также имеет список ссылок на дочерние узлы. Всё остальное опционально.
Пользовательский парсинг дерева данных с простым установлением иерархических связей между узлами даст нам то самое дерево объектов.
Деревья объектов тоже могут быть очень разными — это может быть дерево модели данных, дерево компонентов или виджетов, дерево состояний, и дерево чего вашей душе угодно.
Для начала возьмем дерево данных в JSON, а затем сделаем из него дерево объектов-моделей данных.
Дерево данных в JSON:
{
"computer": {
"system_unit": {
"motherboard": {
"name": "MSI",
"processor": {
"name": "Intel"
},
"video_card": {
"name": "Nvidia"
}
}
},
"monitor": {
"name": "Asus"
},
"keyboard": {
"name": "Logitech"
}
}
}При парсинге мы преобразуем это дерево данных в дерево объектов, где объекты будут располагаться в аналогичной иерархии, будут типизированы и иметь ссылки на родителя и детей.
В примере ниже реализация иерархических зависимостей находится в родительском классе TreeNode:
class TreeNode {
parent;
children = [];
constructor(parent) {
this.parent = parent;
this.parent.children.add(this);
}
}
class Computer extends TreeNode {
constructor(parent) {
super(parent);
}
}
class Monitor extends TreeNode {
name;
constructor(parent, name) {
super(parent);
this.name = name;
}
}Представляете, какие огромные возможности дает такой подход? Аж мурашки по коже.
На основе этих данных мы сделаем:
Полноценную навигацию по дереву. В частности, на основе
parentиchildrenможно реализовать свойстваroot,first,last,previous,next, и т.п.Операции формирования дерева —
addChild,remove, и т.п.
Это позволит нам свободно ходить по дереву и манипулировать им.
Кроме этого, мы реализуем переключатели и множественный выбор узлов, разберемся, с чем это едят. Рассмотрим работу с деревом компонентов и деревом состояний. Возможности типизации дерева, описания и автогенерации кода, инструментов визуального редактирования.
В общем, продолжение следует, я пока обедать, а вы подписывайтесь, чтобы не проворонить выход следующих статей.
Удачи!
Комментарии (59)
dopusteam
16.04.2023 06:42+11В программировании есть два способа реализации объектов — наследование и композиция
Неверно. Наследование и композиция не про реализацию объектов.
Дерево (Map)
Дерево и map, внезапно, - разные структуры
Итак, деревом объектов мы будем называть группу иерархически взаимосвязанных объектов
Это не совсем то, что обычно понимается под деревом. Это осознанно? Например, в классическом определении недопустимым циклы, а тут, видимо, допустимы
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел
У дерева нет корня?
iviv Автор
16.04.2023 06:42-4Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
dopusteam
16.04.2023 06:42+10Это не упрощения, это фактические ошибки
iviv Автор
16.04.2023 06:42-4Я пока не увидел указания ни на одну ошибку, только на ваше непонимание материала. Я бы вам посоветовал задавать вопросы, если что-то непонятно.
dopusteam
16.04.2023 06:42+2Вы очень последовательны - сначала говорите, что не увидели указания на ошибки, а потом ниже отвечаете на мои замечания об ошибках.
В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь
Что такое "дерево класса Map"?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.— Это не определение дерева. Это соглашение о терминах.
Это не ответ. У дерева есть корень?
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
Зачем использовать устоявшиеся термины для обозначения чего то нового?
iviv Автор
16.04.2023 06:42Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?dopusteam
16.04.2023 06:42Если б вы отвечали на вопрос сразу, было бы проще. Я тут же продолжу, если не против.
Можете написать пример того, как в вашем дереве будет выглядеть например алгоритм бинарного поиска? Ну или ещё что нибудь.
iviv Автор
16.04.2023 06:42Напишите пожалуйста пример того, как с помощью ООП будет выглядеть, например, алгоритм бинарного поиска.
Тогда я попробую это же изобразить с помощью TOP.
iviv Автор
16.04.2023 06:42Дерево (Map), полученное в результате их стандартного парсинга, также будем называть деревом данных [...]
— В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь.
iviv Автор
16.04.2023 06:42У дерева нет корня?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.
— Это не определение дерева. Это соглашение о терминах.
iviv Автор
16.04.2023 06:42в классическом определении недопустимым циклы
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
PrinceKorwin
16.04.2023 06:42+1Другими словами ваша модель будет нормально жить с циклическими ссылками?
xxxphilinxxx
16.04.2023 06:42+9Несколько раз прочитал статью, но так и не осознал "огромные возможности": в чем преимущество?
Вы зачем-то смешиваете дерево как структуру однородных данных и иерархию зависимых данных. В вашем примере TreeNode Computer может иметь родителем другой компьютер. Или лампочку. Или сапог. А потомками десять HDD: два внутри, а остальные 8 на складах и попробуй различи, какой где и куда воткнут. Исчезла уникальная информация о связи: в чем смысл, какие типы объектов могут быть, какая множественность допустима, может ли отсутствовать и т.д., так что агрегат (композиция) выродился в контейнер.
Сам термин "дерево" мне не кажется удачным: он давно всем известен как частный случай графа со всеми вытекающими свойствами: например, возможность перебалансировки, что неприемлемо для иерархии.
На основе этих данных мы сделаем:
— Полноценную навигацию по дереву. В частности, на основе parent и children можно реализовать свойства root, first, last, previous, next, и т.п.
— Операции формирования дерева — addChild, remove, и т.п.А давайте не будем, это миллиард раз уже реализовано в библиотеках и велосипедах. Хочется таки увидеть суть и пользу идеи.
Поскольку любая программа — это всегда составной объект
Докажите.
Что-то стало лень печатать, чуть позже накину еще замечаний, так что обязательно разыщите мои каналы в телеграме и ютубе и подпишитесь.
panzerfaust
16.04.2023 06:42+1Несколько раз прочитал статью, но так и не осознал "огромные возможности": в чем преимущество?
А я в этом месте прям явственно почувствовал школу Бугаенко.
iviv Автор
16.04.2023 06:42-3Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
xxxphilinxxx
16.04.2023 06:42+1Я не против упрощений, но в том-то и дело, что до сих пор не понимаю саму вашу идею: то ли хотите дерево использовать в работе с DTO/конфигами, то ли хотите полностью избавиться в коде от агрегаций/композиций в классическом виде через свойство с объектом или коллекцией объектов, то ли просто какой-то частный случай рассматриваете. Где именно такое предлагаете применять и чем это лучше альтернативных практик?
iviv Автор
16.04.2023 06:42В этой статье не было задачи ответить на все эти вопросы. Но если коротко, то без проблем:
В моей практике для организации моделей данных и состояний я использую Дерево-Ориентированный подход.
Подход — означает куда больше, чем просто фреймворк работы с деревьями или набор приемов. Это прямо мышление таким способом.
Но этот способ мышления базируется и на фреймворках, и на приемах и на инструментах.
К примеру, когда я проектирую приложение я его дерево состояний описываю в JSON. Там узлы вида:
{
"type": "TypeName",
"doc": "Node text description",
"props": { ... },
"children": [ ... ]
}
Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание.
И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить.
Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Но подчеркну, это не Дерево Ориентированное программирование как таковое, это всего лишь одно из следствий этого подхода. А подход это способ мышления.
Цель статей — популяризировать подход и привлечь внимание тех, кто занимается развитием языков. Очень нехватает простой языковой конструкции вида:
class MySystemUnit extends ATowerSystemUnit parent Computer children ASystemUnitChild {.....}
Это просто опыт, который говорит, что если ввести в язык всего два ключевых слова, parent и children, то работа с деревьями станет также эффективна, как наследование в ООП.
Это краткий ответ.
Но чтобы это всё рассказать нормально, нужно много чего описать.
Чем и собираюсь заняться.
Спасибо.
a-tk
16.04.2023 06:42+3Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
Сколько раз я за последние 20+ лет слышал эту мантру. По факту не имеющую ни малейшего отношения к реальности.
iviv Автор
16.04.2023 06:42-1Ну, ок, но тут хотя бы возникает возможность сделать визуальный редактор, который не даст делать синтаксические ошибки, поддержит драг-н-дроп перемещение веток, даст подсказки и т.п.
Сейчас толком для этого нет ничего. Каждое ТЗ пишется как бог на душу положит. Это в свою очередь приводит к тому, что менеджеры забывают указать в ТЗ целые разделы приложения, скажем, авторизацию. А программистов привлекают, уже с подписанным ТЗ, согласованным бюджетом, и сроками "надо сделать ко вчера". В итоге недооценка объема проекта, сроков, финансирования. А это конфликт с заказчиком, взаимное недовольство, а иногда суды и скандалы.
Предлагаемый подход — возможный путь решения проблемы.
Но, к Дерево Ориентированному программированию это отношения не имеет. Это всего лишь одно из возможных следствий его применения. И даже, если такой документ ни один менеджер никогда в жизни составить не сможет, это не лишает его тех полезных возможностей, которые он дает.
Спасибо.
xxxphilinxxx
16.04.2023 06:42+1Уже намного понятнее, спасибо. А сущности тоже таким образом описываете или все-таки только состояния? Т.е., насколько подход шире обычного дерева состояний или простого автомата (state machine)? В примерах везде именно сущности, а такая метода все еще не выглядит для меня хорошо подходящей для статичных объектов, а не действий/переходов. Реальный пример был бы очень кстати.
iviv Автор
16.04.2023 06:42Дерево-Ориентированное программирование про способ мышления, про то, как мы себе представляем программу, как ее проектируем и создаем.
С помощью дерева мы можем описывать объекты, данные, состояния и всё, что нам захочется.
Про аналогии с ООП, вы спрашиваете, а можем ли мы с помощью классов описывать не только компьютеры, как в примере выше, но и живые существа?
Здесь также. Это инструмент описания, который расширяет уже существующий инструментарий. И пользоваться им можно в самых разных целях.
dopusteam
16.04.2023 06:42Это легко читаемый документ, с ним может работать не только программист, но и менеджер
Чем этот документ более читаемый чем любой другой? Или с другими документами не могут работать менеджеры и программисты? Менеджеры реально json будут смотреть? Выглядит как ущемление их прав
Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Насколько ж у вас там развесистое дерево получается?
И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить.
Чем это отличается от обычного подхода? Или обычно у вас разрабы не могут работать каждый по своему?
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание.
Тут вообще сильно. Какой эскиз, если даже не начали тех задание пилить? А если оно не нужно, то кто мешает эскиз без этого чудо дерева запилить?
iviv Автор
16.04.2023 06:42-1Чем этот документ более читаемый чем любой другой?
— Тем, что любого другого нет. ТЗ возникает сильно позже.
Насколько ж у вас там развесистое дерево получается?
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
Чем это отличается от обычного подхода?
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.Какой эскиз, если даже не начали тех задание пилить?
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.dopusteam
16.04.2023 06:42Тем, что любого другого нет. ТЗ возникает сильно позже.
Что мешает написать документ без чудо дерева?
Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как
А как же ссылки между узлами? Вы уверены, что просто так получится разделить? Код не обязательно писать "неизвестно как", модули, проекты, компоненты - вот это все в помощь. Как один большой json может быть лучше - для меня загадка все ещё.
При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов
Что мешает код разделить на такие же независимые части? Выглядит так, будто у вас проблема с процессом разработки
Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.
Зачем чудо дерево то? На фигме набросали и всё
Все ваши аргументы про то, что дерево магическим способом все упростит, но вы не привели ни одного примера конкретного, без "в коде тяжело, в дереве просто"
iviv Автор
16.04.2023 06:42— Полное фуфло этот ваш Паваротти.
— О! Тебе удалось побывать на его концерте?
— Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал.
Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
iviv Автор
16.04.2023 06:42-2У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
LedIndicator
16.04.2023 06:42+2На основе этих данных мы сделаем:
— Полноценную навигацию по дереву. В частности, на основе parent и children можно реализовать свойства root, first, last, previous, next, и т.п.
— Операции формирования дерева — addChild, remove, и т.п.Правильно ли я понимаю, что если мне, например, в моём кровавом энтерпрайзе надо достать валидатор из сервиса, то в дерево-ориентированном программировании придётся написать что-то типа:
myService.getParent().getParent().getParent().getChildren()[3].getChildren()[0].getChildren()[5]вместо того, чтобы позволить какому-нибудь спрингу заинжектить бин?
Так себе огромные возможности, если честно.
iviv Автор
16.04.2023 06:42-6Не правильно. Предлагаю вам искать правильные ответы, а не неправильные.
И результат получается положительный.
flancer
16.04.2023 06:42А как правильно? Или вы тоже не знаете?
iviv Автор
16.04.2023 06:42Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent
Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно.
Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
iviv Автор
16.04.2023 06:42-4Но у меня плохие новости для тех, кто пишет
`super().super().super().super().super().super().toString();`
PrinceKorwin
16.04.2023 06:42Это, случайно, не переизобретение DOM?
iviv Автор
16.04.2023 06:42-2Бери выше, это изобретение дерева!
Вообще-то, ожидать в статье для начинающих описания изобретений, мне кажется несколько оптимистичным.
Kotofay
16.04.2023 06:42+3Делал такую систему хранения сложных составных объектов иерархически связанных.
Проблемы следующие -- сложная валидация, сохранение/восстановление, довольно большой расход памяти. Отсутствие теоретической базы стандартной обработки, в отличии от реляционных БД.
Возможности по описанию любых сложных структур действительно неограничены. Основная ценность -- возможность неограниченной деталировки объекта путём добавления всё более подробных/расширенных характеристик/свойств.
В общем виде такую систему хранения можно представить как распределённую файловую систему, с классическими разделителями "/", только в ней "файлы" могут хранить живые ссылки на другие файлы, произвольные наборы данных, в т.ч. неупорядоченных или наоборот поименованных, всё зависит только от фантазии проектировщика хранилища.
iviv Автор
16.04.2023 06:42Всё так и есть, когда речь идет именно о модели данных. И дерево далеко не всегда лучший способ хранения данных, особенно, если в технологии есть хорошие альтернативы.
Читателя я подвожу к другим вариантам использования, об этом я упомянул в конце статьи.
a-tk
16.04.2023 06:42+4Новый стиль статей на хабр: вбросить в заголовке, начать в статье и не довести даже до какого-то подобия логического завершения.
Обычно когда в процессе беглого просмотра вылезает разметка хабра за концом статьи, ответ на вопрос "И?..." так и не бывает получено.
PS: Хорошо хоть рекламы от инфоцыган нету, так что хотя бы попытку можно похвалить.
iviv Автор
16.04.2023 06:42-1У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.a-tk
16.04.2023 06:42Так сделайте оглавление относительно того, стоит ли читателям вообще читать дальнейшие части.
А по поводу анонсов: на Хабре есть огромное кладбище циклов статей, не доживших даже до второй статьи.
iviv Автор
16.04.2023 06:42-3Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.a-tk
16.04.2023 06:42+2А Вы перечитайте свою статью.
Она начинается с того, что обозначена проблема без конкретики, которая выглядит как булшит.
Продолжается введением какого-то понятия, которое не раскрыта.
И обрывается с непонятными перспективами.
Вам предложили обозначить перспективы: пролог (считаем что намёки есть), завязка (аналогично), интрига, кульминация, развязка, эпилог, выводы.
iviv Автор
16.04.2023 06:42-2Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
a-tk
16.04.2023 06:42+1Коль скоро Вы воспринимаете предложения и замечания по написанному как претензии личного плана и переводите всё в эмоциональную плоскость, я устраняюсь из дискуссии.
iviv Автор
16.04.2023 06:42-1Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.
a-tk
16.04.2023 06:42+1Если Вы так реагируете потому что считаете, что я минусую комментарии или статью - то нет, я принципиально не минусую ничего в рамках обсуждений. Кто-то другой выражает это мнение.
Kotofay
16.04.2023 06:42Нужно продолжить. А то не очень понятно, в чём преимущество перед обычными реляционными БД и стандартным ООП.
brakerkir
16.04.2023 06:42+1Популяризировать делегирование, действительно, похвально. По сравнению со множеством статей, восхваляющих наследование, мало материалов по хорошему уместному делегированию. Особенно в учебниках для начинающих. Из-за этого часто вижу монстров с десятком миксинов. Или того хуже люди рожают наследников, не поддерживающих API родителя и не относящихся к той же доменной области.
Но зря Вы так резко из крайности в крайность бросаетесь. Хвалить что-то или кого-то, принижая ценность другого - не слишком правильно. Для каждой ситуации полезен свой инструмент.
iviv Автор
16.04.2023 06:42Я совершенно согласен со всем, за исключением того, что где-то пытаюсь принизить какой-то инструмент. Для каждой ситуации нужен свой инструмент. А Дерево-Ориентированное программирование не замена ООП, а дополнение.
velon
16.04.2023 06:42+1Это всё подозрительно похоже на шаблон "Компоновщик". А про дерево-ориентированную разработку я слышу впервые.
iviv Автор
16.04.2023 06:42Шаблоны можно применять разные. К примеру, в дереве состояний мною широко применяется шаблон Состояние.
Но говорить, что Дерево-Ориентированное программирование похоже на Состояние также неверно, как говорить, что ООП похоже на шаблон Компоновщик.
VladimirFarshatov
16.04.2023 06:42+1Хорошая статья, и тема поднята крайне полезная. В реальности, да: каждое Приложение, пакет, библиотека имеет под капотом свое дерево сущностей, классов и как правило иерархическое. Хранение иерархических данных - отдельная темя, mumps, Cache в помощь, а ранее существовал целый сонм иерархических БД.. Да, собственно те же NoSQl базы а-ля Mongo и пр. всё та же попытка влезть в иерархию объектов.
Главная проблема статьи, кмк, это сумбурный стиль изложения. Писать в теге "просто" и тем более "для начинающих" .. это на мой взгляд очень трудно. Я бы переставил тег на "сложный".. :)
iviv Автор
16.04.2023 06:42Я понемногу перейду к сложностям.
Честно говоря, не ожидал, что будут задавать вопросы, типа есть ли у дерева корень. Это странный опыт.
tessob
Мне казалось, что как раз таки эволюция шла от сложных деревьев к более компактным представлениям с dependency injection & inversion of control. Это более иле менее прослеживается в мире корпоративного софта. Просто когда над кодом работают более одного программиста, то каждому из них надо как-то понимать что там было в голове у того другого Мастера Бансай.
iviv Автор
Если описать тысячу элементов в дереве и тысячу элементов распихать по разным углам кода, то в результате программа будет проще и понятнее, если использовалось дерево.
tessob
Эти 2 множества как-то пересекаются? Я просто перечитал несколько раз, но так и не понял, что вы пытаетесь сказать.
Какие аргументы в пользу того, что станет проще и понятнее, а не наоборот? Просто DI & IoC набрал популярность именно в силу того, что код стал получаться более компактным и менее многословным, а определение объектов/сущностей стало удобно выполнять в рамках семантической иерархии приложения, а не основываясь на последовательность вызова функций/конструкторов.
a-tk
Более того, многие языки программирования пошли по пути упрощения синтаксиса и сокращения бойлерплейта для реализации именно DI&IoC.
iviv Автор
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.