Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.
Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.
Ну, ок, но тут хотя бы возникает возможность сделать визуальный редактор, который не даст делать синтаксические ошибки, поддержит драг-н-дроп перемещение веток, даст подсказки и т.п.
Сейчас толком для этого нет ничего. Каждое ТЗ пишется как бог на душу положит. Это в свою очередь приводит к тому, что менеджеры забывают указать в ТЗ целые разделы приложения, скажем, авторизацию. А программистов привлекают, уже с подписанным ТЗ, согласованным бюджетом, и сроками "надо сделать ко вчера". В итоге недооценка объема проекта, сроков, финансирования. А это конфликт с заказчиком, взаимное недовольство, а иногда суды и скандалы.
Предлагаемый подход — возможный путь решения проблемы.
Но, к Дерево Ориентированному программированию это отношения не имеет. Это всего лишь одно из возможных следствий его применения. И даже, если такой документ ни один менеджер никогда в жизни составить не сможет, это не лишает его тех полезных возможностей, которые он дает.
В этой статье не было задачи ответить на все эти вопросы. Но если коротко, то без проблем:
В моей практике для организации моделей данных и состояний я использую Дерево-Ориентированный подход.
Подход — означает куда больше, чем просто фреймворк работы с деревьями или набор приемов. Это прямо мышление таким способом.
Но этот способ мышления базируется и на фреймворках, и на приемах и на инструментах.
К примеру, когда я проектирую приложение я его дерево состояний описываю в JSON. Там узлы вида: { "type": "TypeName", "doc": "Node text description", "props": { ... }, "children": [ ... ] } Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание. И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить. Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Но подчеркну, это не Дерево Ориентированное программирование как таковое, это всего лишь одно из следствий этого подхода. А подход это способ мышления.
Цель статей — популяризировать подход и привлечь внимание тех, кто занимается развитием языков. Очень нехватает простой языковой конструкции вида:
class MySystemUnit extends ATowerSystemUnit parent Computer children ASystemUnitChild {.....}
Это просто опыт, который говорит, что если ввести в язык всего два ключевых слова, parent и children, то работа с деревьями станет также эффективна, как наследование в ООП.
Это краткий ответ. Но чтобы это всё рассказать нормально, нужно много чего описать. Чем и собираюсь заняться.
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
Всё так и есть, когда речь идет именно о модели данных. И дерево далеко не всегда лучший способ хранения данных, особенно, если в технологии есть хорошие альтернативы.
Читателя я подвожу к другим вариантам использования, об этом я упомянул в конце статьи.
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Если описать тысячу элементов в дереве и тысячу элементов распихать по разным углам кода, то в результате программа будет проще и понятнее, если использовалось дерево.
Мой подход заключается в том, что приложение описывается как дерево состояний в формате JSON. На его основе формируется техническое задание, генерируются шаблоны классов состояний с JDOC, и в runtime формируется дерево состояний. Это же дерево или его ветки в процессе работы приложения могут сериализоваться и десериализоваться для организации команд CTRL+Z и CTRL+Y и других целей.
В итоге образуется целый ряд преимуществ, но это не описать в комментарии.
Очень давно использую этот подход в разных технологиях, и везде успешно. В середине 2000-х я даже пытался книгу об этом написать. С тех пор подходы существенно эволюционировали, но в основе та же суть.
Взялся что-то написать на эту тему, и в процессе прошелся по чужому опыту. Оказалось полезно, уже написано много разного, но и мне есть чего добавить от себя.
Вы продолжаете поливать статью, а я говорил о том, какая реакция на одну и ту же статью будет в разных культурах. Возможно, именно это и лежит в корне проблемы утечки мозгов из России, остальное лишь последствия.
Это не конкурент БД или ООП. Это расширение ООП, если хотите.
Речь идет о двух одинаковых множествах, где в первом случае всё хранится в стандартизированном дереве, а в другом случае, где бог на душу положил.
Сейчас ситуация такова, что каждый разработчик действует по своему усмотрению. И хорошо, если он при этом придерживается неких понятных принципов и известных решений. Но ведь он многое может понимать не так, реализовать не так и т.п.
Обрати внимание, что в смысле организации иерархии классов таких проблем не очень много — наследование поддерживается на уровне языков, много и хорошо прописанная теоретическая база, поставленное обучение, и так далее.
Убери всё это и мы вернемся в 50-е годы прошлого столетия.
Но мы и одновременно находимся на этом уровне в смысле работы с композицией. Нет стандартной поддержки в языках, нет теории и практики, и так далее.
Да, у меня на эту тему штук 10-15 готовых статей лежит неопубликованных.
Честно говоря, я даже понимаю, откуда берутся циклы статей, которые до второй статьи не дошли. Секрет прост:
Если бы я это публиковал на англоязычном ресурсе, кроме спасибо и конкретных советов как улучшить статью, просто бы не было.
На русском ресурсе ситуация такова, что не разобравшись насуют х..в за воротник, чаще всего потому, что с женой проблемы, а не со статьей, и потом недовольные ходят читать продолжение через гугл-переводчик.
Если честно, я ожидал подобного приема тут, но не думал, что это будет так неприятно.
Ну, ок, но тут хотя бы возникает возможность сделать визуальный редактор, который не даст делать синтаксические ошибки, поддержит драг-н-дроп перемещение веток, даст подсказки и т.п.
Сейчас толком для этого нет ничего. Каждое ТЗ пишется как бог на душу положит. Это в свою очередь приводит к тому, что менеджеры забывают указать в ТЗ целые разделы приложения, скажем, авторизацию. А программистов привлекают, уже с подписанным ТЗ, согласованным бюджетом, и сроками "надо сделать ко вчера". В итоге недооценка объема проекта, сроков, финансирования. А это конфликт с заказчиком, взаимное недовольство, а иногда суды и скандалы.
Предлагаемый подход — возможный путь решения проблемы.
Но, к Дерево Ориентированному программированию это отношения не имеет. Это всего лишь одно из возможных следствий его применения. И даже, если такой документ ни один менеджер никогда в жизни составить не сможет, это не лишает его тех полезных возможностей, которые он дает.
Спасибо.
В этой статье не было задачи ответить на все эти вопросы. Но если коротко, то без проблем:
В моей практике для организации моделей данных и состояний я использую Дерево-Ориентированный подход.
Подход — означает куда больше, чем просто фреймворк работы с деревьями или набор приемов. Это прямо мышление таким способом.
Но этот способ мышления базируется и на фреймворках, и на приемах и на инструментах.
К примеру, когда я проектирую приложение я его дерево состояний описываю в JSON. Там узлы вида:
{
"type": "TypeName",
"doc": "Node text description",
"props": { ... },
"children": [ ... ]
}
Это легко читаемый документ, с ним может работать не только программист, но и менеджер.
На основании этого документа генерится дерево классов состояний. Если на них навесить эскизы, то имеем готовый прототип, который можно уже показать заказчику. Ещё до того, как начали писать техзадание.
И дальше, если нужно раскидать работу между программистами, просто раздаешь им ветки, каждому свою. Они цепляют моки и поехали пилить.
Новые программисты на входе смотрят JSON и тут же понимают как весь объем проекта, так и его структуру. Им не надо отдельно объяснять, где что лежит и что от чего зависит.
Но подчеркну, это не Дерево Ориентированное программирование как таковое, это всего лишь одно из следствий этого подхода. А подход это способ мышления.
Цель статей — популяризировать подход и привлечь внимание тех, кто занимается развитием языков. Очень нехватает простой языковой конструкции вида:
class MySystemUnit extends ATowerSystemUnit parent Computer children ASystemUnitChild {.....}
Это просто опыт, который говорит, что если ввести в язык всего два ключевых слова, parent и children, то работа с деревьями станет также эффективна, как наследование в ООП.
Это краткий ответ.
Но чтобы это всё рассказать нормально, нужно много чего описать.
Чем и собираюсь заняться.
Спасибо.
Но у меня плохие новости для тех, кто пишет
`super().super().super().super().super().super().toString();`
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
У меня написано больше десятка вариантов статей на эту тему. Этот вариант я написал и сразу опубликовал, иначе всё это грозит остаться в столе.
Собственно другие не публиковал потому, что либо сходу слишком сложно, либо читать два часа, либо тонна кода. И приходится выбирать.
В итоге я так решил, что буду давать материал порциями, с постепенным усложнением. Какие-то выводы и новые решения появятся позже. Сейчас это рассказ для начинающих на пальцах.
Всё так и есть, когда речь идет именно о модели данных. И дерево далеко не всегда лучший способ хранения данных, особенно, если в технологии есть хорошие альтернативы.
Читателя я подвожу к другим вариантам использования, об этом я упомянул в конце статьи.
Бери выше, это изобретение дерева!
Вообще-то, ожидать в статье для начинающих описания изобретений, мне кажется несколько оптимистичным.
Не правильно. Предлагаю вам искать правильные ответы, а не неправильные.
И результат получается положительный.
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Любая статья, а тем более, статья для уровня начинающих, содержит множество упрощений. В противном случае, легко укопаться в малозначительных деталях, лишь отвлекающих от основной цели статьи.
Если описать тысячу элементов в дереве и тысячу элементов распихать по разным углам кода, то в результате программа будет проще и понятнее, если использовалось дерево.
Мой подход заключается в том, что приложение описывается как дерево состояний в формате JSON. На его основе формируется техническое задание, генерируются шаблоны классов состояний с JDOC, и в runtime формируется дерево состояний.
Это же дерево или его ветки в процессе работы приложения могут сериализоваться и десериализоваться для организации команд CTRL+Z и CTRL+Y и других целей.
В итоге образуется целый ряд преимуществ, но это не описать в комментарии.
Очень давно использую этот подход в разных технологиях, и везде успешно. В середине 2000-х я даже пытался книгу об этом написать. С тех пор подходы существенно эволюционировали, но в основе та же суть.
Взялся что-то написать на эту тему, и в процессе прошелся по чужому опыту. Оказалось полезно, уже написано много разного, но и мне есть чего добавить от себя.
Спасибо за статью!