Комментарии 69
Мне казалось, что как раз таки эволюция шла от сложных деревьев к более компактным представлениям с dependency injection & inversion of control. Это более иле менее прослеживается в мире корпоративного софта. Просто когда над кодом работают более одного программиста, то каждому из них надо как-то понимать что там было в голове у того другого Мастера Бансай.
Если описать тысячу элементов в дереве и тысячу элементов распихать по разным углам кода, то в результате программа будет проще и понятнее, если использовалось дерево.
Если описать тысячу элементов в дереве и тысячу элементов распихать по разным углам кода
Эти 2 множества как-то пересекаются? Я просто перечитал несколько раз, но так и не понял, что вы пытаетесь сказать.
то в результате программа будет проще и понятнее
Какие аргументы в пользу того, что станет проще и понятнее, а не наоборот? Просто DI & IoC набрал популярность именно в силу того, что код стал получаться более компактным и менее многословным, а определение объектов/сущностей стало удобно выполнять в рамках семантической иерархии приложения, а не основываясь на последовательность вызова функций/конструкторов.
Более того, многие языки программирования пошли по пути упрощения синтаксиса и сокращения бойлерплейта для реализации именно DI&IoC.
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.
В программировании есть два способа реализации объектов — наследование и композиция
Неверно. Наследование и композиция не про реализацию объектов.
Дерево (Map)
Дерево и map, внезапно, - разные структуры
Итак, деревом объектов мы будем называть группу иерархически взаимосвязанных объектов
Это не совсем то, что обычно понимается под деревом. Это осознанно? Например, в классическом определении недопустимым циклы, а тут, видимо, допустимы
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел
У дерева нет корня?
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Это не упрощения, это фактические ошибки
Я пока не увидел указания ни на одну ошибку, только на ваше непонимание материала. Я бы вам посоветовал задавать вопросы, если что-то непонятно.
Вы очень последовательны - сначала говорите, что не увидели указания на ошибки, а потом ниже отвечаете на мои замечания об ошибках.
В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь
Что такое "дерево класса Map"?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.— Это не определение дерева. Это соглашение о терминах.
Это не ответ. У дерева есть корень?
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
Зачем использовать устоявшиеся термины для обозначения чего то нового?
Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?
Дерево (Map), полученное в результате их стандартного парсинга, также будем называть деревом данных [...]
— В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь.
У дерева нет корня?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.
— Это не определение дерева. Это соглашение о терминах.
в классическом определении недопустимым циклы
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
>Дерево (Map), полученное в результате их стандартного парсинга [...]
>Дерево и map, внезапно, - разные структуры
— Сорри, я так и не понял, в каких случаях Map, полученный в результате стандартного парсинга XML или JSON не является деревом. Можно пример?
Не моя ветка ( :) ), но вот простой пример: {"a":1, "b":2} => map<string, int>. Нет ключевой возможности задать связи между родительскими и дочерними узлами без дополнительного вмешательства - значит, это еще не представление дерева. Возможно, конечно, например, использование дополнительного контейнера или хранение всех связей еще где-то отдельно, но это ведь уже выходит за возможности самого map, т.к. сама по себе эта структура данных все же одноуровневая.
Спасибо за ответ, но я так и не понял, по каким признакам это не дерево. Это один из вариантов дерева, не более. Даже просто пустой объект является разновидностью дерева. Вырожденного, но всё-же дерева.
Я просто подумал, что я чего-то не знаю, что стандартный парсинг может создавать зацикленные графы или что-то в таком духе. Ну нет так нет.
Вы правы с математической точки зрения, но смотрите не на данные, а на структуры данных, мы же все-таки их обсуждаем: Map без дополнений не способен представить общий случай дерева и дать инструменты для работы с ним, годится только для подмножества (такого же, как и обычный массив). А иначе тогда и NULL надо тоже считать программной реализацией дерева, просто пустого - математически корректно, но совершенно неприменимо.
Так сказать, Map ⊂ Tree, but Map ! implements Tree
Если не брать в рассчет вырожденные случаи, то структурно любая Map, полученная в результате стандартного парсинга, является деревом.
{"a":1, "b":2} - это тоже совершенно нормальное дерево, у которого есть рутовый объект и два дочерних объекта типа int.
Вам про Фому, Вы про Ерему :(
Давайте отделим мух от котлет данные от структур.
Да, если взять json/xml, содержащий древовидные данные, и преобразовать в программные структуры, используя Map и только Map без дополнений и соглашений - это будет древовидное представление древовидных данных. Но у него будет несколько недостатков/особенностей, которых у классического полноценного Tree быть не должно.
Оно не дает инструментов для работы с деревом: хочешь переставлять узлы или даже просто совершать обход - делай это сам. А из дочернего узла к родительскому вообще перейти невозможно - нет ссылки;
Оно не дает никаких гарантий относительно структуры: например, отсутствия циклов или множественных связей между двумя узлами;
Оно позволяет использовать любые типы в качестве узлов, причем даже такие, которые принципиально не могут иметь дочерних узлов: я на это намекал в примере с Map<string, int>. Тип int не является составным, поэтому потребуется, например, дополнительный контейнер;
Оно требует дополнительной информации о связи: уникальный текстовый ключ. В классическом дереве такого нет;
Родительские объекты не имеют собственного значения.
Чуть более сложный случай возьмем: {"root": {"a":1}}. Здесь, очевидно, уже два Map, причем, разных: Map<string, int> для дочернего узла и Map<string, Map<string, int>> для родительского. Их нельзя взять и поменять местами - это разные типы и они не взаимозаменимы. Дочернему нельзя взять и добавить потомков - тип int этого не позволяет. У обоих родительских элементов нет значения; значение есть только у самого последнего потомка - единица.
Разница, которую я пытаюсь объяснить, в том, что даже если представляемые данные являются частным случаем дерева сами по себе (Data ⊂ TreeSet), то комбинация Map, использованных для этого представления, все равно из-за указанных выше причин не способна самостоятельно предоставить полноценную работу ни с общим случаем дерева, ни даже с представленным (Map ! implements TreeInterface) и годится только для ограниченного набора действий и в основном в режиме read-only.
По этой же причине нельзя назвать деревом и обычный массив, хотя он тоже может представлять некоторые древовидные данные с ограниченной функциональностью - например, [[1,2],[3,4]]. Рутовый объект не имеет своего значения, но имеет пару потомков, каждый из которых тоже не имеет своего значения и имеет еще пару потомков типа int.
Да, если взять json/xml, содержащий древовидные данные, и преобразовать в программные структуры, используя Map и только Map без дополнений и соглашений - это будет древовидное представление древовидных данных.
- На этом можно остановиться, поскольку именно об этом и шла речь, остальное обсуждение далеко за рамками предмета дискуссии.
Несколько раз прочитал статью, но так и не осознал "огромные возможности": в чем преимущество?
Вы зачем-то смешиваете дерево как структуру однородных данных и иерархию зависимых данных. В вашем примере TreeNode Computer может иметь родителем другой компьютер. Или лампочку. Или сапог. А потомками десять HDD: два внутри, а остальные 8 на складах и попробуй различи, какой где и куда воткнут. Исчезла уникальная информация о связи: в чем смысл, какие типы объектов могут быть, какая множественность допустима, может ли отсутствовать и т.д., так что агрегат (композиция) выродился в контейнер.
Сам термин "дерево" мне не кажется удачным: он давно всем известен как частный случай графа со всеми вытекающими свойствами: например, возможность перебалансировки, что неприемлемо для иерархии.
На основе этих данных мы сделаем:
— Полноценную навигацию по дереву. В частности, на основе parent и children можно реализовать свойства root, first, last, previous, next, и т.п.
— Операции формирования дерева — addChild, remove, и т.п.
А давайте не будем, это миллиард раз уже реализовано в библиотеках и велосипедах. Хочется таки увидеть суть и пользу идеи.
Поскольку любая программа — это всегда составной объект
Докажите.
Что-то стало лень печатать, чуть позже накину еще замечаний, так что обязательно разыщите мои каналы в телеграме и ютубе и подпишитесь.
Несколько раз прочитал статью, но так и не осознал "огромные возможности": в чем преимущество?
А я в этом месте прям явственно почувствовал школу Бугаенко.
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Я не против упрощений, но в том-то и дело, что до сих пор не понимаю саму вашу идею: то ли хотите дерево использовать в работе с DTO/конфигами, то ли хотите полностью избавиться в коде от агрегаций/композиций в классическом виде через свойство с объектом или коллекцией объектов, то ли просто какой-то частный случай рассматриваете. Где именно такое предлагаете применять и чем это лучше альтернативных практик?
В этой статье не было задачи ответить на все эти вопросы. Но если коротко, то без проблем:
В моей практике для организации моделей данных и состояний я использую Дерево-Ориентированный подход.
Подход — означает куда больше, чем просто фреймворк работы с деревьями или набор приемов. Это прямо мышление таким способом.
Но этот способ мышления базируется и на фреймворках, и на приемах и на инструментах.
К примеру, когда я проектирую приложение я его дерево состояний описываю в JSON. Там узлы вида:
{
"type": "TypeName",
"doc": "Node text description",
"props": { ... },
"children": [ ... ]
}
Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание.
И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить.
Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Но подчеркну, это не Дерево Ориентированное программирование как таковое, это всего лишь одно из следствий этого подхода. А подход это способ мышления.
Цель статей — популяризировать подход и привлечь внимание тех, кто занимается развитием языков. Очень нехватает простой языковой конструкции вида:
class MySystemUnit extends ATowerSystemUnit parent Computer children ASystemUnitChild {.....}
Это просто опыт, который говорит, что если ввести в язык всего два ключевых слова, parent и children, то работа с деревьями станет также эффективна, как наследование в ООП.
Это краткий ответ.
Но чтобы это всё рассказать нормально, нужно много чего описать.
Чем и собираюсь заняться.
Спасибо.
Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
Сколько раз я за последние 20+ лет слышал эту мантру. По факту не имеющую ни малейшего отношения к реальности.
Ну, ок, но тут хотя бы возникает возможность сделать визуальный редактор, который не даст делать синтаксические ошибки, поддержит драг-н-дроп перемещение веток, даст подсказки и т.п.
Сейчас толком для этого нет ничего. Каждое ТЗ пишется как бог на душу положит. Это в свою очередь приводит к тому, что менеджеры забывают указать в ТЗ целые разделы приложения, скажем, авторизацию. А программистов привлекают, уже с подписанным ТЗ, согласованным бюджетом, и сроками "надо сделать ко вчера". В итоге недооценка объема проекта, сроков, финансирования. А это конфликт с заказчиком, взаимное недовольство, а иногда суды и скандалы.
Предлагаемый подход — возможный путь решения проблемы.
Но, к Дерево Ориентированному программированию это отношения не имеет. Это всего лишь одно из возможных следствий его применения. И даже, если такой документ ни один менеджер никогда в жизни составить не сможет, это не лишает его тех полезных возможностей, которые он дает.
Спасибо.
Уже намного понятнее, спасибо. А сущности тоже таким образом описываете или все-таки только состояния? Т.е., насколько подход шире обычного дерева состояний или простого автомата (state machine)? В примерах везде именно сущности, а такая метода все еще не выглядит для меня хорошо подходящей для статичных объектов, а не действий/переходов. Реальный пример был бы очень кстати.
Дерево-Ориентированное программирование про способ мышления, про то, как мы себе представляем программу, как ее проектируем и создаем.
С помощью дерева мы можем описывать объекты, данные, состояния и всё, что нам захочется.
Про аналогии с ООП, вы спрашиваете, а можем ли мы с помощью классов описывать не только компьютеры, как в примере выше, но и живые существа?
Здесь также. Это инструмент описания, который расширяет уже существующий инструментарий. И пользоваться им можно в самых разных целях.
Это легко читаемый документ, с ним может работать не только программист, но и менеджер
Чем этот документ более читаемый чем любой другой? Или с другими документами не могут работать менеджеры и программисты? Менеджеры реально json будут смотреть? Выглядит как ущемление их прав
Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Насколько ж у вас там развесистое дерево получается?
И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить.
Чем это отличается от обычного подхода? Или обычно у вас разрабы не могут работать каждый по своему?
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание.
Тут вообще сильно. Какой эскиз, если даже не начали тех задание пилить? А если оно не нужно, то кто мешает эскиз без этого чудо дерева запилить?
Чем этот документ более читаемый чем любой другой?
— Тем, что любого другого нет. ТЗ возникает сильно позже.
Насколько ж у вас там развесистое дерево получается?
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
Чем это отличается от обычного подхода?
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.
Какой эскиз, если даже не начали тех задание пилить?
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.
Тем, что любого другого нет. ТЗ возникает сильно позже.
Что мешает написать документ без чудо дерева?
Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как
А как же ссылки между узлами? Вы уверены, что просто так получится разделить? Код не обязательно писать "неизвестно как", модули, проекты, компоненты - вот это все в помощь. Как один большой json может быть лучше - для меня загадка все ещё.
При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов
Что мешает код разделить на такие же независимые части? Выглядит так, будто у вас проблема с процессом разработки
Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.
Зачем чудо дерево то? На фигме набросали и всё
Все ваши аргументы про то, что дерево магическим способом все упростит, но вы не привели ни одного примера конкретного, без "в коде тяжело, в дереве просто"
— Полное фуфло этот ваш Паваротти.
— О! Тебе удалось побывать на его концерте?
— Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал.
Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
Вы ловко увиливаете от вопросов и не показали ни одного примера, как ваше дерево что то решает.
Вы посмотрите примерно ход дискуссии
- Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
- Чем этот документ более читаемый чем любой другой?
- Тем, что любого другого нет. ТЗ возникает сильно позже
- Что мешает написать документ без чудо дерева?
- Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал.Но это не мешает вам так уверенно критически высказываться
Вы ловко увиливаете от вопросов и не показали ни одного примера, как ваше дерево что то решает.
— Попробуйте человеку объяснить преимущества ООП на одном маленьком примере, если этот человек с ООП не знаком и на ваши утверждения отвечает, что всё это возможно сделать и без ООП.
Преимущества возникают, когда нужно выстраивать хотя бы мало-мальски сложные структуры иерархических данных, иметь инструменты ее модификации, навигации, контроля целостности структуры данных, и многое другое.
Имея всё это, открывается новый уровень возможностей, которые сейчас возможны только теоретически, а на практике слишком сложны. Так и в ООП есть огромное количество возможностей, которые как бы есть и без него, но реализовать их вне ООП было настолько неудобно, что никто этого не делал.
И тут я вынужден признать, что в рамках комментария на подобные вопросы ответить невозможно. Всё, что могу посоветовать, это набраться терпения и ждать следующих статей. Или самому попробовать исследовать это направление.
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
На основе этих данных мы сделаем:
— Полноценную навигацию по дереву. В частности, на основе parent и children можно реализовать свойства root, first, last, previous, next, и т.п.
— Операции формирования дерева — addChild, remove, и т.п.
Правильно ли я понимаю, что если мне, например, в моём кровавом энтерпрайзе надо достать валидатор из сервиса, то в дерево-ориентированном программировании придётся написать что-то типа:
myService.getParent().getParent().getParent().getChildren()[3].getChildren()[0].getChildren()[5]вместо того, чтобы позволить какому-нибудь спрингу заинжектить бин?
Так себе огромные возможности, если честно.
Не правильно. Предлагаю вам искать правильные ответы, а не неправильные.
И результат получается положительный.
А как правильно? Или вы тоже не знаете?
Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent
Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно.
Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
Но у меня плохие новости для тех, кто пишет
`super().super().super().super().super().super().toString();`
Это, случайно, не переизобретение DOM?
Делал такую систему хранения сложных составных объектов иерархически связанных.
Проблемы следующие -- сложная валидация, сохранение/восстановление, довольно большой расход памяти. Отсутствие теоретической базы стандартной обработки, в отличии от реляционных БД.
Возможности по описанию любых сложных структур действительно неограничены. Основная ценность -- возможность неограниченной деталировки объекта путём добавления всё более подробных/расширенных характеристик/свойств.
В общем виде такую систему хранения можно представить как распределённую файловую систему, с классическими разделителями "/", только в ней "файлы" могут хранить живые ссылки на другие файлы, произвольные наборы данных, в т.ч. неупорядоченных или наоборот поименованных, всё зависит только от фантазии проектировщика хранилища.
Новый стиль статей на хабр: вбросить в заголовке, начать в статье и не довести даже до какого-то подобия логического завершения.
Обычно когда в процессе беглого просмотра вылезает разметка хабра за концом статьи, ответ на вопрос "И?..." так и не бывает получено.
PS: Хорошо хоть рекламы от инфоцыган нету, так что хотя бы попытку можно похвалить.
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
Так сделайте оглавление относительно того, стоит ли читателям вообще читать дальнейшие части.
А по поводу анонсов: на Хабре есть огромное кладбище циклов статей, не доживших даже до второй статьи.
Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.
А Вы перечитайте свою статью.
Она начинается с того, что обозначена проблема без конкретики, которая выглядит как булшит.
Продолжается введением какого-то понятия, которое не раскрыта.
И обрывается с непонятными перспективами.
Вам предложили обозначить перспективы: пролог (считаем что намёки есть), завязка (аналогично), интрига, кульминация, развязка, эпилог, выводы.
Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.
Нужно продолжить. А то не очень понятно, в чём преимущество перед обычными реляционными БД и стандартным ООП.
Популяризировать делегирование, действительно, похвально. По сравнению со множеством статей, восхваляющих наследование, мало материалов по хорошему уместному делегированию. Особенно в учебниках для начинающих. Из-за этого часто вижу монстров с десятком миксинов. Или того хуже люди рожают наследников, не поддерживающих API родителя и не относящихся к той же доменной области.
Но зря Вы так резко из крайности в крайность бросаетесь. Хвалить что-то или кого-то, принижая ценность другого - не слишком правильно. Для каждой ситуации полезен свой инструмент.
Это всё подозрительно похоже на шаблон "Компоновщик". А про дерево-ориентированную разработку я слышу впервые.
Хорошая статья, и тема поднята крайне полезная. В реальности, да: каждое Приложение, пакет, библиотека имеет под капотом свое дерево сущностей, классов и как правило иерархическое. Хранение иерархических данных - отдельная темя, mumps, Cache в помощь, а ранее существовал целый сонм иерархических БД.. Да, собственно те же NoSQl базы а-ля Mongo и пр. всё та же попытка влезть в иерархию объектов.
Главная проблема статьи, кмк, это сумбурный стиль изложения. Писать в теге "просто" и тем более "для начинающих" .. это на мой взгляд очень трудно. Я бы переставил тег на "сложный".. :)
Что вы так все набросились сразу минусовать. Вполне свежая мысль в программировании. Есть над чем подумать. Да, возможно это "дорога не туда", но почему-бы не по размышлять над этим.
Tree Oriented Programming