Введение

В рамках практического изучения ООП написал набор классов, реализующих построение древовидной структуры любого уровня сложности для VBA. Как вы знаете, сам VBA кроме массивов и коллекций (объект Collection) в готовом виде ничего более не имеет. Пределом мечтаний на данный момент является внешний компонент Dictionary из библиотеки Microsoft Scripting Runtime. В виду этакой скудности приходится городить конструкты типа Dictionary с элементами в виде других Dictionary, либо изобретать свои классы. Чем я и занялся. Теперь, если вам потребуется выстроить дерево, то вы можете воспользоваться моим готовым решением.

Прошу прощения у новичков - статья не предназначена для начинающих, да вам это и не надо. Поэтому всякие мелочи разжёвывать не буду - нет времени, а те, кому это может пригодиться, способны разобраться по краткому описанию. Относительно сложные или тонкие моменты прокомментированы.

PerfectTree: свойства класса

Моя структура базируется на классе PerfectTree. Данный класс с точки зрения прикладного программиста содержит лишь корень нашего дерева (свойство Root) и несколько методов, о которых позже. Root – это экземпляр класса Node (узел). Узел Root создаётся одновременно с созданием экземпляра класса PerfectTree. Дальнейший рост дерева идёт от этого корня.

Node: свойства класса

Наше дерево представляет собой некое множество узлов, объединенных друг с другом отношениями родитель – потомки. То есть каждый узел имеет ОДНОГО родителя и может иметь потомков (одного или больше), а может и не иметь. Любой узел имеет следующие свойства:

Чтобы лучше уяснить себе назначение основных свойств узла, поизучайте эту иллюстрацию:

Nodes: свойства класса

Последний имеющийся класс – класс Nodes – представляет из себя просто коллекцию узлов. Они могут быть объединены по какому-то признаку, как, например, коллекция в свойстве Children класса Node объединена по принципу одного родителя, либо вы можете создать коллекцию с произвольными узлами.

PerfectTree: методы класса

Node: методы класса

Nodes: методы класса

Некоторые замечания

Как грамотно прятать внутреннюю кухню ваших объектов?

Одна из самых полезных и неочевидных вещей, которой я обучился во время создания данных классов, - это способ сокрытия от пользователя нюансов внутренней реализации ваших объектов и защите их внутренних структур.

Например, возьмём такое свойство класса Node, как Level. Если вы сделаете так:

То через некоторое время поймёте, что:

1. У вас нет защиты от дурака. Кто угодно сможет присвоить неправильное значение свойству Level и сломает всю гармонию вашей структуры, которую, вы вообще-то говоря, обязаны защищать, если пишите компоненты для других. Если же вы будете в обработчике Let городить проверку присваиваемого значения на корректность, то получится слишком сложно и, в конце концов, медленно.

2. Осознав вышесказанное, вы захотите закрыть свойство Level на запись из пользовательских модулей. Ведь действительно, при создании нового узла его Level вычисляется из родительского +1 и у пользователя нет никаких практических причин писать в это свойство. Но как это сделать? Вы в начале наивно используете директиву Friend, но она вам никак не поможет с этой проблемой.

3. Тогда вы уберёте обработчик Property Let вообще. И через 5 минут столкнётесь с проблемой, что непонятно, как инициировать поле pLevel при создании нового экземпляра объекта Node. "C хрена ли?" - скажете вы. Объясняю: у вас есть родительский Node. Находясь в нём, вы вызываете метод CreateChild, в котором создаёте новый экземпляр класса Node. Но вы не можете передать туда информацию. Вы можете менять только Public или Friend свойства, открытые на запись! А мы как раз хотим от них избавиться. WTF?

Я нигде не нашёл источников информации, где об этом чётко и ясно было бы рассказано. Я спросил на форумах. И нашёлся хороший человек (спасибо KSV), который набросал пример, но я этот пример осознавал крайне долго. И вот этот механизм я вам намерен разжевать подробно.

Интерфейс класса

первое, что необходимо сделать, это объявить класс-предок или класс-интерфейс. В нём мы объявляем пустое публичное свойство Let - то есть именно то свойство, которое мы хотели бы скрыть в реализации класса Node.

Далее при объявлении наших основных классов, в частности Node, мы должны сослаться на наш интерфейс:

Ну и сам механизм, ради которого всё это затевалось:

Почему мы имеем право присвоить переменной TempINode значение CreateChild? Не смотря на то, что это переменные разных классов, класс Node - потомок класса INode, поэтому мы можем переменной родительского класса присвоить ссылку на экземпляр класса-потомка. Наоборот нельзя.

Далее мы помним, что свойство Level в классе Inode объявлено публичным, поэтому мы легко меняем его, но поскульку в TempINode у нас экземпляр класса Node, то фактически мы меняем свойство pLevel переменной CreateChild. Вот и всё.

Если вы полезете в код моих классов, то именно этого примера вы не найдёте, но обнаружите массу свойств и методов, которые объявлены в INode, и, используя описанный выше механизм,

Резюмирую: мы смогли избавиться от метода Let Level на уровне класса Node. Теперь никто не сможет нарушить целостность вашей структуры за счёт присвоения Level-у неправильного значения, а вы избавлены от утомительных проверок. Таким образом всё, что мы хотим спрятать пробрасывается через класс-предок INode. Пользователи не будут создавать экземпляры INode, поэтому нам наплевать, что там "намусорено", нам важно, что всё, что мы хотели скрыть или закрыть на запись, скрыто и закрыто.

Конвееры

Обратите внимание, как удобно использовать коллекции Nodes. Дело в том, что многие методы класса Nodes возвращают тоже экземпляры класса Nodes, поэтому вы можете формировать конвеер из методов и получить в конце то, что вам нужно:

Скачать PerfectTree

Файл XLSM (версия 0.20 от 22.05.2017)

ZIP архив с CLS файлами (для импорта классов в ваш файл)

Принимаются заявки на исправление ошибок и реализацию новой функциональности.

История изменений

• Версия 0.19 от 19.05.2017. Первая опубликованная версия.

• Версия 0.20 от 22.05.2017. Исправлены ошибки в Node.CreateChild, в Nodes.FilterByName. На отладочную печать теперь выводится Payload. Добавлены методы Nodes.GetArrayOfPayload, Nodes.GetArrayDistinctName.

• Версия 0.21 от 23.05.2017. Пересобрал проект из-за непонятных багов в 0.20.

Приехали...

К моему глубокому огорчению, данное решение работает нестабильно. При запуске файла, если нажать кнопку "Создать дерево" на листе Data, то вы скорее всего получите ошибку Type mismatch или произойдёт крах Excel. При этом я почти на 99% уверен, что ошибок в коде нет. Если войти в IDE и начать делать ничего не значащие изменения, перекомпиляции, то код начинает работать. Всё это происходит скорее всего из-за ошибок в реализации ООП в MS Office. Если кто-то сможет мне указать на работающие способы заставить классы работать без существенной переделки архитектуры классов (например, я категорически не хочу отказываться от интерфейсных классов), то буду очень признателен, но что-то мне подсказывает, что этого не случится.