Часть 3. LVOOP
LabVIEW OOP не поддерживает множественное наследование - это означает, что дети могут наследовать поля и методы только от одного родителя. Что делать, если требуется обратиться к методу класса, который не связан общим родителем?
В языке программирования, который поддерживает множественное наследование было бы проще в решении этой проблемы: наследуем и всё. Увы и ах, но наследование не бывает частичным, поэтому бонусом будут получены поля и методы от всякого. При разработке приложения это приведёт к приличному бардаку и путанице в проекте.
С другой стороны, есть языки, которые не поддерживают множественное наследование, например Java или C#. Однако, в этих языках программирования используются механизм интерфейсов. Интерфейс определяет контракт доступа к какому-то объекту. Важно понимать, что интерфейс не реализует сам метод, он предоставляет лишь доступ к нему. Одним и тем же интерфейсом могут пользоваться множество объектов, но реализация методов, которые содержит интерфейс, будет определена либо в каждом классе на свой манер, либо будет использоваться реализация метода по умолчанию из того класса, который предоставил этот интерфейс. Как раз то, что нужно, чтобы добраться до какого-то метода вне родственных классов.
В LabVIEW нет ни интерфейсов, ни множественного наследования и возникает вопрос: чего делать? я хочу конкретный метод(вероятно с конкретной реализацией) вооон того класса, который не от кого не зависит. Придётся выкручиваться
мы можем создать отдельный класс с реализацией нужного метода и наследоваться от него(ку-ку, дублирование кода), либо напрямую обратиться к объекту нужного класса для вызова метода(инкапсуляция, прости). И если в тексте это выражается в двух строчках быдло-кода(именно так), то в LabVIEW это будет выглядеть вот так:
Вот пожалуйста: у нас в методе класса Test создаётся объект класса ClassCalculator и вызывается его метод add. Поля мы берём из класса Test, вот пожалуйста – открыли доступ к set-еру класса ClassCalculator. Ну как?... Оно? Начал искать информацию про «интерфейсы в LabVIEW», нашел темы на Lava.org...Так там этой проблеме посвящены десятки тем с демонстрациями изворотливости на всякий вкус, посмеялся. В общем - это первая фишка, которая будет троллить LVOOP-шника.
Второй фишкой будет отсутствие конструктора. Зачем в ООП-языках конструктор используют? Правильно, чтобы инициализировать поля некоторыми первоначальными значениями. Я наивно полагал, что делаю тоже самое, когда открываю кластер с полями объекта и устанавливаю в них какие-то значения. Ничего подобного: как были нули – так и остаются до тех пор, пока в явном виде не вызовешь сеттер для заполнения полей. Или нужно где-то галочку поставить? Еще одна фишка, которой пользуются эффективно и изящно – вложенные классы(nested class), но в LVOOP этого нет. Конечно же есть там какие-то варианты сделать нечто подобное – но это так же как и с интерфейсом. Мол, вложенные классы не часто используются( это я прочитал на одном из форумов
), поэтому и не нужны они, а если очень надо – вот вам кусочек как это можно обойти-заменить. А мне бы эта фишка пригодилась для того, чтобы не создавать отдельный дубль-класс с минимальными изменениями или объединить мелкие классы вместе внутри класса.
Так что в LabVIEW придётся более детально прорабатывать архитектуру проекта и сетовать на недостаточный уровень абстракции (хотя бы из-за отсутствия интерфейсов). Либо вообще изолировать классы друг от друга, используя их как кирпичи для построения финального приложения, в этом есть определенное здравое зерно. Возможно, в 2018 версии что-то изменилось, а то я в 2014-ой работаю.
Еще один пример напоследок как не надо делать: определили класс «прямоугольник» и класс «монитор».
Это два абсолютно не связанных логически между собой класса. Тем не менее, мы хотим наследовать реализованный метод из прямоугольника, чтобы нарисовать монитор прямоугольной формы. Берём и наследуем, да? На этом моменте мурашки пробегают и становится не по себе…особенно, если метод «рисовать» был унаследован от абстрактного класса «Геометрические фигуры». Поэтому, будьте внимательны и осторожны, дабы не ошибиться с проектированием домика. Не жалейте времени на качественный чертёж, тогда ваш объект прослужит верой и правдой долгие годы.
Трёх китов LVOOP вытягивает, уже хорошо. Дальше буду обозревать конкретные шаблоны(паттерны) проектирования: основные, порождающие, структурные, поведенческие. Вообще в википедии я насчитал около 60 паттернов, в хитовой книге Эрика и Элизабет Фримен приведены 12(может побольше, надо пролистать), в книге «Приёмы объектно-ориентированного проектирования» под авторством Гамм, Хелм, Джонсон, Влиссидес – 23. Посмотрю, сравню с тем, что уже приводится из готового для LabVIEW, сопоставлю с информацией из книг и что-нибудь разберу.
Многа буков, кто дочитал - тот молодец
Полезная ссылка:
https://forums.ni.com/t5/LabVIEW-Develo ... -p/3523820