ООП - объектно-ориентированое программирование

[XAN]

есть проблемка, в нашем распоряжении есть только LabView 7.1 (бесплатная версия, без ключа, в библиотеках отсутствуют приборы и сама папка Object-Oriented , немог бы кто-нибудь выложить мне эти приборы (желательно чтобы были совместимы с 7.1 версией)

[Eugen Graf]

В версии 7.1 нет LVOOP. Даже если кто то выложит примеры, ты не сможешь их открыть.
Я думаю тебе нужно GOOP. Скачай и установи:
/viewtopic.php?f=62&t=91

После этого у тебя в меню появится Tools->LabVIEW GOOP Wizzard

Что касается примеров по GOOP, то начни с этого:
http://forums.lavag.org/Starting-with-GOOP-t9066.html

Eugen Graf это я, так что можешь задавать вопросы по этому примеру.

[XAN]

Можете памоч найти описание данных примеров в Example ,Object-Oriented ? можна на английском. Кстати установили версию 8.2

[Eugen Graf]

Начни с Graphics.lvproj

[XAN]

пытаемся(
неасоба выходит, немнога нашол но ...

[XAN]

Совсем не осталось времени для работы, помогите хотя бы найти сайт с готовым рассмотрением прибора.

[Eugen Graf]

Вот делаю сейчас очередно, но очень большой проект на базе LVOOP, в котором около 10 различных типов приборов, при чём три типа из них могут добавлятся динамически до бесконечности. У каждого типа свой коммуникационный протокол. При этом задействованы TCP/IP, CAN, RS-232 и RS-422. Я даже не знаю сколько времени мне понадобилось бы для реализации этого проекта без LVOOP

А у вас как обстоит дело с LVOOP? Кто нибудь пользовался им в каком нибудь проекте?

[Pavel Krivozubov]

А у вас как обстоит дело с LVOOP? Кто нибудь пользовался им в каком нибудь проекте?

Лично я - пока нет. И предпосылок к использованию классов не вижу. Мне непонятно их назначение, если уже есть кластеры в которых так же можно динамически добавлять объекты. Может быть конечно в мега-проектах где используются много интерфейсов они и удобней, но у меня пока таких проектов не было. А, впрочем был в самом начале проект в котором одновременно использовались RS-232, GPIB, VXI, TCP/IP (это моя самая первая работа, я про нее уже писал), но и там я без всяких классов на LabVIEW 7.0 написал программу за 3 месяца, причем с нуля.
Да и вообще слишком прилизывать LabVIEW под формат текстовых языков мне кажется лишнее. Сидят тут рядом со мной дармоеды сишники, у которых только и разговоров что про классы, наследование, RFC, MFC и прочие прелести жизни. В итоге клиент-серверное прилижение пишется три года И что самое смешное до сих пор фиксятся какие-то баги А у меня студенты аналогичный проект за два месяца написали. Вообщем это одна из причин по которой на ооп я пересаживаться не спешу. Хотя если ты меня убедишь в обратном, может и попробую когда - нибудь

[Eugen Graf]

Мне непонятно их назначение, если уже есть кластеры в которых так же можно динамически добавлять объекты.

Да он в принципе даже не динамический, просто им как то немного удобнее пользоваться. Занимает меньше места и программа становится более понятной. А вот наследованием я пока ещё не пользовался, пока не знаю куда прицепить это наследование. Как только где нибудь найду применение для наследования или полиморфизма, напишу об этом.

А убеждать тебя (или кого нибудь) в необходимости применения классов я не собираюсь, это личное дело каждого программиста

[mzu2006]

Мне непонятно их назначение, если уже есть кластеры в которых так же можно динамически добавлять объекты

Да он в принципе даже не динамический, просто им как то немного удобнее пользоваться.

Да и вообще слишком прилизывать LabVIEW под формат текстовых языков мне кажется лишнее.

добавлю свои 5 копеек. LVOOP использую в паре текущих проектов в основном как средство самодисциплины. Если следовать
одному из шаблонов дизайна то гораздо сложнее напортачить с кодом. Наппример, в одном из проектов у меня есть доступ к
база данных в странном формате. Вот база данных - это объект сделанный по шаблону singleton.

В итоге клиент-серверное прилижение пишется три года

это к вопросу о владении тем инструментом, что
используешь.

Вообще, ПМСМ, в C++ объекты нужнее чем в Labview. Взять, хотя бы реализацию подсчёта указателей и прочего управления памятью. в Labview этот аспект применения классов не актуален.

[Eugen Graf]

Хотелось бы поднять эту тему. Конкретно меня интересует кто вник и занялся этим. Мы на немецком форуме чуть не передрались обсуждая LVOOP. Кстати написал два урока по LVOOP для начинающих на немецком, собираюсь в скором времени перевести их на русский.

[mzu2006]

Использую объекты для самодисциплины. Например, конфигурационная информация, части которой взаимосвязаны. При доступе на запись, данные проверяются на соответствие друг-другу

[Eugen Graf]

А можно примерчик? Спс.
И почему именно в данном случае OOP ?

Вот в том случае, что я описал выше понятно. Есть несколько дивайсов, каждый из них является реальным объектом, который я отобразил виртуально. При этом у каждого такого объекта есть свой параллельный цикл, что эти объекты оживляет.
Мне, как программисту, это даёт возможность думать как человек и относится к этим объектам как к живым тварям (в смысле творениям).

P.S. именно параллельное сосуществование оживляет обьект.

[toto]

Плохо нам в свое время ООП в ВУЗе преподавали, до сих пор теперь не могу осмыслить, зачем оно нужно особенно в LabView. Если будут какие-то примеры описания для "школьников", с удовольствием почитаю :)

[mzu2006]

дивайсов, каждый из них является реальным объектом

На мой взгляд, здесь имеет место конфликт нескольких понятий.
1. Объект LVOOP (GOOP, C++, etc), далее object.
2. Объект в жизни, т.е. "тварь живая", далее тварь.

object: это "умный" кластер. Такое вот хранилище данных позволяющее реализовать инкапсуляцию, наследование и полиморфизм.
тварь, это нечто реагирующее на внешние и внутренние события-стимулы, некоторыми внешними и внутренними реакциями.

Q&A:
вопрос 1: можно (и разумно ли) иметь в программе object-ы, не имеющие смысла как твари? Я считаю, да. Примеры:
1. Хочется иметь
конфигурационные настройки программы, собранные в одном месте. При изменении одной из них, хочется проверять новое значение на соответствие
другим значениям. Хочется иметь несколько конфигураций и из нескольких определять одну общую, так, чтобы она была тоже корректна. Например,
при расширении программы мы просто делаем другой класс, наследующий от первого, и добавляющий дополнительную конфигурацию итд итп.

2. Спектры поглощения. Каждый спектр поглощения, это object. Над ними можно производить операции: +, -, *, /, разложить на компоненты, итд итп.
Каждый спектр задан на своей сетке, т.е. перед выполнением операций их, возможно, надо привести к одной сетке итд итп.

вопрос 2: Почему ООП, а не, скажем, кластеры?
1. Сложно перепутать разные объекты. Один раз я был technical lead в команде, делающей программу для управления Spatial Light Modulator (SLM) и несколькими камерами. Дело было в 7.1. Дескриптор камеры и SLM был кластером (typedef). По несчастливой случайности, они оба были автоматически приводимы друг к другу. Я написал шаблон для другого работника. При детализации шаблона он перепутал проводок, и завёл дескриптор SLM на вход vi, управляющей камерой. При этом, когда в системе одна камера, это не проявлялось. Когда добавили вторую камеру, началось необъяснимое. Минус месяц Я теперь знаю, что эта проблема имеет решение в рамках 7.1 (refnum), но с тех пор - только объекты.

2. Ну и, естественно, традиционные слова про инкапсуляцию ...

вопрос 3: а как соотносятся objects и твари? Да, никак. Программист может используя инструмент objects создать некоторое подобие тварей. Например, класс MessageDrivenThread в java. По-моему, такие objects называются actors. Можно каждый object чисто механически сделать тварью. Но, по-моему, не нужно, тем более в где понятия время жизни и область действия не определены.

вопрос 4: Есть ли твари, которые сложно запихать в objects? Да, например, внешнее окружение выполняющейся программы (ОС + другие программы + итд)

Да, и вот пример с конфигурацией (сейчас в процессе доработки):

Eg, а что у тебя за дискуссия была на немецкой ветке форума?