Улучшение масштабируемости измененного алгоритма обхода дерева перед порядком
Рекомендации библиотеки классов по реализации IDisposable неверны.
Я не часто делюсь этим, но считаю, что руководство по реализации по умолчанию для IDisposable совершенно неверно.
Моя проблема не в перегрузке Dispose и удалении элемента из финализации, а в том, что я презираю, как происходит вызов для освобождения управляемых ресурсов в финализаторе. Я лично считаю, что должно быть сгенерировано исключение (и да, со всей той мерзостью, которая возникает при добавлении его в поток финализатора).
Причиной этого является то, что если вы являетесь клиентом или сервером IDisposable, существует понимание, что вы не можете просто оставить объект, лежащий вокруг, для завершения. Если вы это сделаете, то это недостаток дизайна / реализации (в зависимости от того, как он остался лежать и / или как он выставлен), поскольку вы не знаете о времени жизни экземпляров, о которых вам следует знать.
Я думаю, что этот тип ошибок / ошибок находится на уровне условий гонки / синхронизации с ресурсами. К сожалению, при вызове перегрузки Dispose эта ошибка никогда не материализуется.
Редактировать: я написал сообщение в блоге на эту тему, если кому-то интересно:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for -IDisposable.aspx
3 ответа
Я слышал, что люди делали это раньше, по тем же причинам, да.
Обратите внимание, что вы теряете несколько небольших преимуществ алгоритма, делая это
- в обычном режиме. , вы можете определить количество потомков узла с помощью ((right - left + 1) div 2). Иногда это может быть полезно, например, если вы отображаете счетчик в древовидной структуре, который должен включать количество дочерних элементов, которые будут найдены дальше по дереву
- Исходя из вышесказанного, легко выбрать все листовые узлы - WHERE (right = left + 1).
Это довольно второстепенные преимущества, которые в любом случае могут вам не пригодиться, хотя для некоторых шаблонов использования они, очевидно, удобны.
Тем не менее, похоже, что материализованные пути могут быть более полезным для вас, как предложено выше.
Думаю, вам лучше подумать о другом способе хранения деревьев. Если ваше дерево широкое, но не слишком глубокое (что кажется вероятным для случая, который вы предложили), вы можете сохранить полный список предков вплоть до корня для каждого узла. Таким образом, для изменения узла не требуется касаться каких-либо узлов, кроме изменяемого.
You can split your table into two: the first is (node ID, node value), the second (node ID, child ID), which stores all the edges of the tree. Insertion and deletion then become O(tree depth) (you have to navigate to the element and fix what is below it).
The solution you propose looks like a B-tree. If you can estimate the total number of nodes in your tree, then you can choose the depth of the tree beforehand.