Да, если взять json/xml, содержащий древовидные данные, и преобразовать в программные структуры, используя Map и только Map без дополнений и соглашений - это будет древовидное представление древовидных данных.
- На этом можно остановиться, поскольку именно об этом и шла речь, остальное обсуждение далеко за рамками предмета дискуссии.
Спасибо за ответ, но я так и не понял, по каким признакам это не дерево. Это один из вариантов дерева, не более. Даже просто пустой объект является разновидностью дерева. Вырожденного, но всё-же дерева.
Я просто подумал, что я чего-то не знаю, что стандартный парсинг может создавать зацикленные графы или что-то в таком духе. Ну нет так нет.
Вы ловко увиливаете от вопросов и не показали ни одного примера, как ваше дерево что то решает.
— Попробуйте человеку объяснить преимущества ООП на одном маленьком примере, если этот человек с ООП не знаком и на ваши утверждения отвечает, что всё это возможно сделать и без ООП.
Преимущества возникают, когда нужно выстраивать хотя бы мало-мальски сложные структуры иерархических данных, иметь инструменты ее модификации, навигации, контроля целостности структуры данных, и многое другое.
Имея всё это, открывается новый уровень возможностей, которые сейчас возможны только теоретически, а на практике слишком сложны. Так и в ООП есть огромное количество возможностей, которые как бы есть и без него, но реализовать их вне ООП было настолько неудобно, что никто этого не делал.
И тут я вынужден признать, что в рамках комментария на подобные вопросы ответить невозможно. Всё, что могу посоветовать, это набраться терпения и ждать следующих статей. Или самому попробовать исследовать это направление.
Напишите пожалуйста пример того, как с помощью ООП будет выглядеть, например, алгоритм бинарного поиска. Тогда я попробую это же изобразить с помощью TOP.
— Полное фуфло этот ваш Паваротти. — О! Тебе удалось побывать на его концерте? — Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал. Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно. Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
Чем этот документ более читаемый чем любой другой?
— Тем, что любого другого нет. ТЗ возникает сильно позже.
Насколько ж у вас там развесистое дерево получается?
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
Чем это отличается от обычного подхода?
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии. В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.
Какой эскиз, если даже не начали тех задание пилить?
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип. Для небольшого приложения это день работы программиста.
Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел. — Это не определение дерева. Это соглашение о терминах.
Я совершенно согласен со всем, за исключением того, что где-то пытаюсь принизить какой-то инструмент. Для каждой ситуации нужен свой инструмент. А Дерево-Ориентированное программирование не замена ООП, а дополнение.
Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.
- На этом можно остановиться, поскольку именно об этом и шла речь, остальное обсуждение далеко за рамками предмета дискуссии.
Если не брать в рассчет вырожденные случаи, то структурно любая Map, полученная в результате стандартного парсинга, является деревом.
{"a":1, "b":2} - это тоже совершенно нормальное дерево, у которого есть рутовый объект и два дочерних объекта типа int.
Спасибо за ответ, но я так и не понял, по каким признакам это не дерево. Это один из вариантов дерева, не более. Даже просто пустой объект является разновидностью дерева. Вырожденного, но всё-же дерева.
Я просто подумал, что я чего-то не знаю, что стандартный парсинг может создавать зацикленные графы или что-то в таком духе. Ну нет так нет.
>Дерево (Map), полученное в результате их стандартного парсинга [...]
>Дерево и map, внезапно, - разные структуры
— Сорри, я так и не понял, в каких случаях Map, полученный в результате стандартного парсинга XML или JSON не является деревом. Можно пример?
— Попробуйте человеку объяснить преимущества ООП на одном маленьком примере, если этот человек с ООП не знаком и на ваши утверждения отвечает, что всё это возможно сделать и без ООП.
Преимущества возникают, когда нужно выстраивать хотя бы мало-мальски сложные структуры иерархических данных, иметь инструменты ее модификации, навигации, контроля целостности структуры данных, и многое другое.
Имея всё это, открывается новый уровень возможностей, которые сейчас возможны только теоретически, а на практике слишком сложны. Так и в ООП есть огромное количество возможностей, которые как бы есть и без него, но реализовать их вне ООП было настолько неудобно, что никто этого не делал.
И тут я вынужден признать, что в рамках комментария на подобные вопросы ответить невозможно. Всё, что могу посоветовать, это набраться терпения и ждать следующих статей. Или самому попробовать исследовать это направление.
Напишите пожалуйста пример того, как с помощью ООП будет выглядеть, например, алгоритм бинарного поиска.
Тогда я попробую это же изобразить с помощью TOP.
— Полное фуфло этот ваш Паваротти.
— О! Тебе удалось побывать на его концерте?
— Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал.
Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
Я понемногу перейду к сложностям.
Честно говоря, не ожидал, что будут задавать вопросы, типа есть ли у дерева корень. Это странный опыт.
Шаблоны можно применять разные. К примеру, в дереве состояний мною широко применяется шаблон Состояние.
Но говорить, что Дерево-Ориентированное программирование похоже на Состояние также неверно, как говорить, что ООП похоже на шаблон Компоновщик.
Об этом я и говорю в самых первых словах статьи.
Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent
Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно.
Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
— Тем, что любого другого нет. ТЗ возникает сильно позже.
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.
Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
Я пока не увидел указания ни на одну ошибку, только на ваше непонимание материала. Я бы вам посоветовал задавать вопросы, если что-то непонятно.
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.
— Это не определение дерева. Это соглашение о терминах.
— В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь.
Дерево-Ориентированное программирование про способ мышления, про то, как мы себе представляем программу, как ее проектируем и создаем.
С помощью дерева мы можем описывать объекты, данные, состояния и всё, что нам захочется.
Про аналогии с ООП, вы спрашиваете, а можем ли мы с помощью классов описывать не только компьютеры, как в примере выше, но и живые существа?
Здесь также. Это инструмент описания, который расширяет уже существующий инструментарий. И пользоваться им можно в самых разных целях.
Я совершенно согласен со всем, за исключением того, что где-то пытаюсь принизить какой-то инструмент. Для каждой ситуации нужен свой инструмент. А Дерево-Ориентированное программирование не замена ООП, а дополнение.
Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.