Вы ловко увиливаете от вопросов и не показали ни одного примера, как ваше дерево что то решает.
— Попробуйте человеку объяснить преимущества ООП на одном маленьком примере, если этот человек с ООП не знаком и на ваши утверждения отвечает, что всё это возможно сделать и без ООП.
Преимущества возникают, когда нужно выстраивать хотя бы мало-мальски сложные структуры иерархических данных, иметь инструменты ее модификации, навигации, контроля целостности структуры данных, и многое другое.
Имея всё это, открывается новый уровень возможностей, которые сейчас возможны только теоретически, а на практике слишком сложны. Так и в ООП есть огромное количество возможностей, которые как бы есть и без него, но реализовать их вне ООП было настолько неудобно, что никто этого не делал.
И тут я вынужден признать, что в рамках комментария на подобные вопросы ответить невозможно. Всё, что могу посоветовать, это набраться терпения и ждать следующих статей. Или самому попробовать исследовать это направление.
Напишите пожалуйста пример того, как с помощью ООП будет выглядеть, например, алгоритм бинарного поиска. Тогда я попробую это же изобразить с помощью TOP.
— Полное фуфло этот ваш Паваротти. — О! Тебе удалось побывать на его концерте? — Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал. Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно. Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
Чем этот документ более читаемый чем любой другой?
— Тем, что любого другого нет. ТЗ возникает сильно позже.
Насколько ж у вас там развесистое дерево получается?
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
Чем это отличается от обычного подхода?
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии. В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.
Какой эскиз, если даже не начали тех задание пилить?
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип. Для небольшого приложения это день работы программиста.
Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел. — Это не определение дерева. Это соглашение о терминах.
Я совершенно согласен со всем, за исключением того, что где-то пытаюсь принизить какой-то инструмент. Для каждой ситуации нужен свой инструмент. А Дерево-Ориентированное программирование не замена ООП, а дополнение.
Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.
Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.
Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.
— Попробуйте человеку объяснить преимущества ООП на одном маленьком примере, если этот человек с ООП не знаком и на ваши утверждения отвечает, что всё это возможно сделать и без ООП.
Преимущества возникают, когда нужно выстраивать хотя бы мало-мальски сложные структуры иерархических данных, иметь инструменты ее модификации, навигации, контроля целостности структуры данных, и многое другое.
Имея всё это, открывается новый уровень возможностей, которые сейчас возможны только теоретически, а на практике слишком сложны. Так и в ООП есть огромное количество возможностей, которые как бы есть и без него, но реализовать их вне ООП было настолько неудобно, что никто этого не делал.
И тут я вынужден признать, что в рамках комментария на подобные вопросы ответить невозможно. Всё, что могу посоветовать, это набраться терпения и ждать следующих статей. Или самому попробовать исследовать это направление.
Напишите пожалуйста пример того, как с помощью ООП будет выглядеть, например, алгоритм бинарного поиска.
Тогда я попробую это же изобразить с помощью TOP.
— Полное фуфло этот ваш Паваротти.
— О! Тебе удалось побывать на его концерте?
— Нет, мне Беня напел.
Уважаемый, два слова — "Tree" и "Oriented", составленные вместе, впервые в жизни вы увидели только на днях в этой статье, ни разу в жизни не щупали это вживую, и ваши знания об этом основаны исключительно на тех крохах информации, которую я здесь опубликовал.
Но это не мешает вам так уверенно критически высказываться.
Доказывать полезность какого-то инструмента — бессмысленная трата времени. Молоток не станет отверткой. Но и отвертка не заменит молоток.
У меня нет ни малейшего желания разжевывать это тем, кто пришел ко мне не за знаниями, а чтобы поспорить. Если бы вы хотели узнать что-то новое, то и вопросы были бы совсем другими, и тон.
Желающим получить информацию я с удовольствием отвечаю.
Я понемногу перейду к сложностям.
Честно говоря, не ожидал, что будут задавать вопросы, типа есть ли у дерева корень. Это странный опыт.
Шаблоны можно применять разные. К примеру, в дереве состояний мною широко применяется шаблон Состояние.
Но говорить, что Дерево-Ориентированное программирование похоже на Состояние также неверно, как говорить, что ООП похоже на шаблон Компоновщик.
Об этом я и говорю в самых первых словах статьи.
Что-то знаю, что-то нет, вот буду рад если помогут.
Что касается моего опыта, и я об этом планирую написать, то не рекомендуется использовать вызовы вида parent.parent.parent
Узел вправе обращаться только к своему родителю или ребенку, но не к их родителям и их детям соответственно.
Это обеспечивает минимум проблем при изменении структуры дерева, или переиспользования ветки в другом месте.
Дискуссионным остается вопрос, можно ли обращаться к предкам через из поиск по интерфейсу вверх по дереву. Тут я не вижу прям особых проблем. Но это не предмет дискуссии на этом этапе изложения материала.
— Тем, что любого другого нет. ТЗ возникает сильно позже.
— Может быть достаточно большим. Но его легко разделить на несколько документов по веткам, и так далее. В любом случае, этот документ категорически проще, чем изучение чужого кода, написанного неизвестно как.
— При обычном подходе несколько разрабов занимаются проектом, и рамки их активности никак не определены или определены нечетко. В итоге возникают конфликты, которые решаются при слиянии.
В ситуации с деревом, каждому разрабу дается своя ветка, которую он пилит. Ее границы и зависимости четко определены. Это резко снижает возможность конфликтов.
— Представь себе, именно так. Просто берется на фигме какой-нибудь набор компонентов под какой-то фиксированный размер, накидываются состояния, добавляются переходы между ними, и вот уже можно щупать прототип.
Для небольшого приложения это день работы программиста.
Я отвечаю на ваши комментарии, чем бы это ни было.
Дерево класса Map получается если в Dart распарсить JSON дерево.
У дерева всегда есть корень, зачем об этом дополнительно писать каждый раз? Я, возможно, не понимаю вопрос, или вы просто решили впустую тратить время?
— Как уже было сказано, это не классическое определение. Такая цель не ставилась. Это соглашение о терминах, не отрицающее общепринятые определения.
Я пока не увидел указания ни на одну ошибку, только на ваше непонимание материала. Я бы вам посоветовал задавать вопросы, если что-то непонятно.
Иерархическая взаимосвязь у нас будет означать, что каждый узел имеет ссылку на свой родительский узел.
— Это не определение дерева. Это соглашение о терминах.
— В результате парсинга данных может быть получено дерево класса Map. Именно об этом и идет речь.
Дерево-Ориентированное программирование про способ мышления, про то, как мы себе представляем программу, как ее проектируем и создаем.
С помощью дерева мы можем описывать объекты, данные, состояния и всё, что нам захочется.
Про аналогии с ООП, вы спрашиваете, а можем ли мы с помощью классов описывать не только компьютеры, как в примере выше, но и живые существа?
Здесь также. Это инструмент описания, который расширяет уже существующий инструментарий. И пользоваться им можно в самых разных целях.
Я совершенно согласен со всем, за исключением того, что где-то пытаюсь принизить какой-то инструмент. Для каждой ситуации нужен свой инструмент. А Дерево-Ориентированное программирование не замена ООП, а дополнение.
Вы как бы продолжаете настаивать на своей правоте, но видна не ваша правота, а даже не знаю, как это назвать. Злоба? Критиканство? Не могу подобрать правильного слова.
Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
Это не конкурент БД или ООП. Это расширение ООП, если хотите.
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.
Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.