Comments 16
Спасибо за статью. Очень интересно
На сайте-демонстрации при попытке нарисовать свое дерево оставьте поле со значениями пустое и просто кликните Draw it! -> Вы получите Internal Server Error
На сайте-демонстрации при попытке нарисовать свое дерево оставьте поле со значениями пустое и просто кликните Draw it! -> Вы получите Internal Server Error
0
ну это же демонстрация, зачем ее ломать, не думаю что сайт на heroku вообще выдержит нагрузку…
0
Не знаю — не знаю
Да я, собственно, и не собирался ломать. Если честно, было лень вводить какие-либо значения и для быстроты просто нажал на кнопку :)
Возможно во мне сыграло профессиональное чувство тестировщика :)
Вы уж извините, если что не так
Да я, собственно, и не собирался ломать. Если честно, было лень вводить какие-либо значения и для быстроты просто нажал на кнопку :)
Возможно во мне сыграло профессиональное чувство тестировщика :)
Вы уж извините, если что не так
0
Вот так будет более в стиле Ruby:
if node.right != nil #=> unless node.right.nil?
while(true) #=> loop do block
if node.right != nil #=> unless node.right.nil?
while(true) #=> loop do block
0
Картинка нарисована случаем не в iTeXmacs?
+1
while true => while node, а break убрать
0
По-моему вместо «walk» используют термин «traverse» в случае графов.
А так больше всего паример рисование порадовал :p
А так больше всего паример рисование порадовал :p
0
> потдерево
пофиксите, плз…
пофиксите, плз…
-3
Нехорошее же дерево, не балансирующееся. И плюс, строить сложносвязанные структуры на языках типа Руби крайне неразумно — оверхед огромный и по памяти, и по скорости работы.
+1
Фотматирование пляшет. Код на гитхабе невозможно читать.
Ещё ооочень много неидеоматического руби-кода. Как уже выше говорили `if node.left != nil` => `unless node.left`, `if node.left == nil` => `if node.left`. Код метода has_one_child_only? можно сократить более чем в два раза, используя xor: `has_left_children? ^ has_right_children?`.
Именования родом из жавы: `heightRight`, `heightLeft`. Также, обычно не пишут методы is_xxx?.. Принято писать xxx?..
Вместе с методом add для добавления в коллекцию новых элементов в руби почти всегда делают метод << (можно как алиас метода add).
Ещё жабьи уши видны в while-условиях со скобочками: `while(true)`.
По дизайну.
Поля root и total_nodes должны быть объявлены через attr_reader, не attr_accessor. Зачем давать пользователю библиотеки менять эти значения?
Опциональный первый параметр в конструкторе дерева не нужен. Странное решение вообще какое-то. Почему одно значение в дерево можно передавать при создании, а не два или не десять? Я не вижу причины.
Методы add и add2 — какая между ними разница? Зачем их два? Неочевидно.
Дерево не балансируется — это тоже верно замечено. Вообще говоря, такие деревья не нужны.
Ещё всякие методы-итераторы (вроде walk) сейчас делают адаптивными в зависимости от того передан ли блок в метод. Если блок передаётся — происходит просто обход дерева, если нет — возвращается Enumerator. Чтобы понятней было о чём я говорю, взгляните на Enumerable.map.
Ну и вообще, то, что walk_* методы возвращают строки — это по меньшей мере странно. На больших объёмах данных это будет вызывать ненужную нагрузку на память, GC и процессор. И потом: неочевидно, что делать, если элементы дерева строки, которые сами содержат запятые. Как потом парсить аутпут walk_* методов?
Но начинание хорошее, продолжайте. Руби несёт в мир добро.
Ещё ооочень много неидеоматического руби-кода. Как уже выше говорили `if node.left != nil` => `unless node.left`, `if node.left == nil` => `if node.left`. Код метода has_one_child_only? можно сократить более чем в два раза, используя xor: `has_left_children? ^ has_right_children?`.
Именования родом из жавы: `heightRight`, `heightLeft`. Также, обычно не пишут методы is_xxx?.. Принято писать xxx?..
Вместе с методом add для добавления в коллекцию новых элементов в руби почти всегда делают метод << (можно как алиас метода add).
Ещё жабьи уши видны в while-условиях со скобочками: `while(true)`.
По дизайну.
Поля root и total_nodes должны быть объявлены через attr_reader, не attr_accessor. Зачем давать пользователю библиотеки менять эти значения?
Опциональный первый параметр в конструкторе дерева не нужен. Странное решение вообще какое-то. Почему одно значение в дерево можно передавать при создании, а не два или не десять? Я не вижу причины.
Методы add и add2 — какая между ними разница? Зачем их два? Неочевидно.
Дерево не балансируется — это тоже верно замечено. Вообще говоря, такие деревья не нужны.
Ещё всякие методы-итераторы (вроде walk) сейчас делают адаптивными в зависимости от того передан ли блок в метод. Если блок передаётся — происходит просто обход дерева, если нет — возвращается Enumerator. Чтобы понятней было о чём я говорю, взгляните на Enumerable.map.
Ну и вообще, то, что walk_* методы возвращают строки — это по меньшей мере странно. На больших объёмах данных это будет вызывать ненужную нагрузку на память, GC и процессор. И потом: неочевидно, что делать, если элементы дерева строки, которые сами содержат запятые. Как потом парсить аутпут walk_* методов?
Но начинание хорошее, продолжайте. Руби несёт в мир добро.
+4
>> Пока я реализовывал этот метод, я понял красоту и простоту одной из самых лучших возможностей ruby: блоки. Когда алгоритм находит следующий узел для обработки, он просто отдает его вызывающей программе. Это позволяет ходить по дереву и быть полностью независимым от действий, которые мы хотим выполнить на каждом узле.
Это относится не только к руби, так как может быть реализовано не только с помощью блоков, но и лямбд и даже объектов. А вообще этот подход называется visitor pattern.
Это относится не только к руби, так как может быть реализовано не только с помощью блоков, но и лямбд и даже объектов. А вообще этот подход называется visitor pattern.
0
Sign up to leave a comment.
Создание бинарного дерева