Собираюсь серьёзно занятся в ближайшем будущем объектно-ориентированым программированием в LabVIEW. Тема на самом деле очень интересная и достойна занять почётное место среди уроков для продвинутых программистов LabVIEW.
И так начнём. Для начала стоит посмотреть вот это видео:
В этом видео достаточно просто объясняется, как использавать ООП в LabVIEW и вообще что это такое.
Поясняю, если непонятно.
Для начала создаётся объект. Но что же такое объект, тем более виртуальный, то есть не существующий на самом деле? Виртуальный объект в моём понимании это отображение реального объекта (такого как автомобиль) всеми позволяемыми способами в программе. Если непонятно то можете представить себе настоящий, реальный автомобиль и его рисунок на бумаге. Так вот рисунок это виртуальный объект, отображающий реальный. Несложно?
Как же можно нарисовать автомобиль в LabVIEW?
Конечно почти невозможно отобразить весь автомобиль с помощью языка программирования. Можно нарисовать его вид снаружи, симулировать работу мотора, показать вращение колёс, создать программу-симулятор для уроков вождения. Но весь автомобиль со всеми его возможностями и поведением очень сложно и наверное даже невозможно отобразить. Ведь и рисунок на бумаге это всего лишь красивая картинка вида снаружи, а где его функциональность? Где крутящиеся колёса например, как выглядит мотор спрятанный под капотом?
Так вот программист должен постараться найти все "нужные" для своего проекта свойства (proprties) и функции (mеthods) используемого в программе объекта и записать их на бумагу или нарисовать так называемую UML-Diagramm.
Например в том видео создаётся объект "автомобиль" который имеет одно единственное свойство "цвет". Позже создаются две функции "скажи какого цвета" и "покрась в цвет". Так же можно создать например свойство автомобиля "скорость" и функции к этому свойству "с какой скоростью мы едем" и функцию "жми на газ". В общем, как сказано выше, любое свойство и функции, которые должен иметь автомобиль именно в вашей программе.
Но фантазии нет предела!
Объектно-оринтированное программирование было создано для людей, которые не хотят или не имеют возможности углублятся в "настоящее" программирование, но сами хотят добится результата. Так вот, ООП разрешает думать по-человечески, и одновременно создавать программы. Кстати той же концепции придерживается National Instruments при создании такого интересного языка программирования как LabVIEW.
Здраствуйте, Вы неподскажетие где можно найти информацию о объектно-ориентированном программировании или проектировании. Разработка интерфейсов этим методом. sup85@mail.ru
Смотри на LAVA, там очень много информации по ООП, правда на английском. Если возникнут какие то конкретные вопросы, можно пообсуждать здесь. Меня тоже очень интерессует эта тема.
А что касается разработки драйверов, то для этого имеется темплейт в LabVIEW. Можно обойтись и без темплейта. Надо просто создать несколько приборов:
инициализация
запись на прибор
запрос данных с прибора
деинициализация
Можно и нужно делать детальнее, для этого надо поближе познакомится с прибором, читать документацию и т.д.
Конкретно по драйверам и ООП:
записываешь все свойства и функции прибора и начинаешь их программировать. Но не надо забывать, что на данный момент, LabVIEW поддерживает OOP by Value, а не OOP by Reference. Это очень затрудняет использование классов в параллельных процессах.
Сейчас пишу программу-пользовательский интерфейс для одного прибора, делаю всё на ООП. Надеюсь получится.
В общем первый проект с использованием закончен. Всё работает, всё в проекте понятно благодаря этому удобному механизму программирования. Я использовал в проекте 7 независимых друг от друга классов, т.е. наследование не использовал. Буду использовать в последующих проектах. Вот выкладываю пару скринов.
Неужели это такая необходимая вещь в LV? ИМХО не тот выбран путь ni, если и использовать ООП, то уж на C'ях или Jave писать, ибо среды разработки приложений для этих языков помощнее будут.
Да это совсем несложно и очень удобно. Но в любом случае, если нехочешь, можешь не пользоваться.
Обойтись конечно можно без ООП, LabVIEW это уже само собой объектно ориентированное явление.
То, что это несложно, было понятно еще с видео презентаций
Интересно, что они еще прикрутят в следующих версиях, у меня уже есть несколько предложений...
Считай что пока я делаю абстрактные оболочки для объектов в моей программе.
Например возьми объект VISA. Он тоже сделан по такому принципу. В начале, при конфигурации ты задаёшь некоторые параметры - это class members, потом открываешь, считываешь, пишешь на порт и закрываешь - это functions. Если будешь думать в таком направленни, то поймёшь, что LabVIEW это уже ООП язык.
И используя LVOOP, делаешь то же самое. Придумываешь обьект, например Media Player. Создаёшь кластер, который имеет все нужные особенности объекта для твоей программы. Например: размер окна и статус. И шлёпаешь несколько нужных функций - воспроизвести файл, остановить воспроизведение, увеличить размер окна ну и тому подобное.
Ну и всё, пользуйся классом. Получается у тебя удобная оболочка, всё по полкам, особеено интересно для больших проектов, где достаточно много таких объектов.
В моём примере (см. картинки выше) прога должна была управлять симулятором вращения, клима-установкой и общаться с измерительным прибором. Я сделал три класса с теми же названиями. Остальные классы внутренние, вспомогательные - т.е. это не реальные объекты. Всего получилось семь классов.
Без введения классов LV не является ООП языком в полной степени, например, ты привел пример про VIS'у- в таком ключе думать обязательно надо, однако данный пример отражает только свой-ва абстракции и инкапсуляции, про полиморфизм и наследование он в явном и даже приближенном виде не говорит.
В VISA как раз всё это есть. Сам VISA это родительский класс. У него есть несколько наследователей: последовательный порт, PXI, USB ну и т.д. При выборе одного из этих наследователей в LABVIEW, автоматически применяется полиморфизм на выбор последующих функций, иначе в среде обработки возникает ошибка (использован не тот класс). Я думаю как раз в случае с разработкой VISA всё это дело было применено.
По-моему мы сейчас с тобой запутаемся в глубине абстракций. Исходя из представлений LV я бы не стал называть PXI, USB и т.п. наследующими "класс" VISA. Механизм наследования и перегрузки я бы назвал условным в данном случае.
Про дополнения:
1) Привязка данных (помнишь, я раньше об этом говорил), причем не через DS и SV
2) Расширенная возможность использования сборок (аналогия с файлом манифеста и конфига)
Crowbar писал(а):
По-моему мы сейчас с тобой запутаемся в глубине абстракций. Исходя из представлений LV я бы не стал называть PXI, USB и т.п. наследующими "класс" VISA. Механизм наследования и перегрузки я бы назвал условным в данном случае.
Да уж, мы не разработчики LabVIEW, непонятно как они там думали, VISA - вещь уже с возрастом. Я думаю такое называется "виртуальный интерфейс".
Crowbar писал(а):
Про дополнения:
1) Привязка данных (помнишь, я раньше об этом говорил), причем не через DS и SV
2) Расширенная возможность использования сборок (аналогия с файлом манифеста и конфига)
Хотя это все не обязательно.
Чес гря не очень врубаюсь о чём ты. Видимо мой русский хромает
Устал я от кластеров, пока не слишком поздно, начну апгрейдить последний проект с использованием LVOOP в версии 8.2.1. Нужен более высокий уровень абстракции и нормальные коллекции.
Итак, как я понял конструктор спрятан от реализации пользователем, по сути установка дефолтных значений контролов кластера класса и есть конструктор.
Деструкторы и освобождение памяти, утечка- как с этим обстоят дела? LV используют собственный процесс для работы с памятью (это не сборщик мусора, но что-то отдаленно напоминающее).
Как работать с классами в параллельном потоке, datalocking- я так понял, надо держать ссылку на тело классса (т.е использовать queue или notifier), а что происходит если я напрямую раздвою класс по значению на два потока- будет 2 разные копии?
Crowbar писал(а):Устал я от кластеров, пока не слишком поздно, начну апгрейдить последний проект с использованием LVOOP в версии 8.2.1. Нужен более высокий уровень абстракции и нормальные коллекции.
Итак, как я понял конструктор спрятан от реализации пользователем, по сути установка дефолтных значений контролов кластера класса и есть конструктор.
Деструкторы и освобождение памяти, утечка- как с этим обстоят дела? LV используют собственный процесс для работы с памятью (это не сборщик мусора, но что-то отдаленно напоминающее).
Как работать с классами в параллельном потоке, datalocking- я так понял, надо держать ссылку на тело классса (т.е использовать queue или notifier), а что происходит если я напрямую раздвою класс по значению на два потока- будет 2 разные копии?
Конструктор и деструктор не нужны. Конструктор это и есть, как ты написал - дифолтные значения, а деструктор, ну скажем так когда прибор заканчивает своё выполнение, то и память освобождается.
В общем класс это тот же кластер, абсолютно ничем не отличается. Раздвоишь класс, получишь две копии, вот и всё.
Ещё раз повторяю - класс это тот же кластер, ничего нового.