LabVIEW Portal

В чем собственно говоря разница между терминами OOP; GOOP и LVOOP?

Пока понятна одна единственная принципиальная разница:
- GOOP работает через reference, а LVOOP работает через value.

Есть еще различия между ними?

LVOOP "by value" это нормально (типично LabVIEW). И потом наверняка LVOOP "by value" будет работать теоретически во много раз быстрее чем GOOP "by reference" (референц был всегда медленней).
К тому же GOOP не бесплатное удовольствие. Кстати знает кто сколько стоит GOOP?
Исходя из этого пока теоретически мой выбор падает на LVOOP.
Хотя сходу возникает вопрос о возможности использования LVOOP и GOOP в одном проекте. (Если такая необходимость возникнет). Не создаст ли это больше проблем? Есть у кого уже в этом вопросе практический опыт?

Что пока я так и не понял, так это отличие OOP и LVOOP?

Предполагаю, что отличие только в том, что:
LVOOP - поддерживает только:
- Encapsulation
- Inheritance
- и частично Polymorphismus
А классическое OOP может значительно больше.

toto писал(а):Вот прочитал я эту статью, и ... не дело не в статье :) просто много лет программируя в LabView вижу, что специалисты (не программисты) легко понимают LabView, и в то же время вижу как программисты (Delphi, Си) загоняют их в тупик пытаясь объяснить приемущество ООП, то есть суть конечно понятна, но не все так сдорово в реальности, так возникает вопрос, надо ли ломать привычные стереотипы и переходить на ООП?

Вчера нашел классное видео о LVOOP от NI (на нем.).
Mогу только порекомендовать:
https://ni.adobeconnect.com/_a56821929/p79152328/

Igor_G писал(а):В чем собственно говоря разница между терминами OOP; GOOP и LVOOP?

основное отличие в том, что OOP это такое абстрактное понятие. А GOOP и LVOOP инструменты, помогающие реализовать OOP в .

Igor_G писал(а): Кстати знает кто сколько стоит GOOP?

GOOP бесплатно, один из вариантов лежит здесь: http://zone.ni.com/devzone/cda/tut/p/id/3391
второй здесь: http://www.sciware.com.au/goopdeveloper/index.html
Авторы сами от него отказываются...

Igor_G писал(а):опрос о возможности использования LVOOP и GOOP в одном проекте.

нецелесообразно, но возможно. Например, использование старых наработок. У Вас будут 2 независимые иерархии объектов.

Igor_G писал(а):Что пока я так и не понял, так это отличие OOP и LVOOP?

Вопрос не имеет смысла ввиду вышесказанного (самый первый ответ)

Igor_G писал(а):LVOOP - поддерживает только:

более корректная формулировка: "LVOOP позволяет реализовать"

Igor_G писал(а):- и частично Polymorphism

Почему частично?

Igor_G писал(а):сделал перевод таблицы

первая строка: я бы сказал не параметры, а данные
вторая строка: не понятно о чем говорится
третья строка: я бы убрал слово "параметры" целиком, т.к. функции "знают" с какими параметрами им работать и в обычном ("императивном") программировании.

Вообще, парадигм программирования много. Почему Вы упомянули только эти две?

основное отличие в том, что OOP это такое абстрактное понятие. А GOOP и LVOOP инструменты, помогающие реализовать OOP в .

ОК. Я почему тогда С++ оперирует только с термином ООП?

нецелесообразно, но возможно. Например, использование старых наработок. У Вас будут 2 независимые иерархии объектов.

Пока еще не знаю. Все еще на стадии обсуждения. Делать или нет. До того как делать вопрос пока не дошел. Еще нет конкретных требований к проекту. Я сейчас пытаюсь понять, что возможно и как. Решение о начале проекта не будет раньше февраля - марта.

Почему частично?

Я о образованию вообще электроинженер ТЭЦ и систем электроснабжения. В Германии 12 лет назад по своему профилю работы не нашел. Пришлось кардинально перепрофилироваться ;0)
Все что я сейчас могу это результат самообразования (на базе хорошего советского образования).
Поэтому я очень даже могу заблуждаться. Но насколько я понял господина Саллер (автор видео).
Он говорит, что пока LabVIEW поддерживает только один из принципов Polymorphismus. Т.е. тот, что разрешает Классам Детей переписывать функции Классов Родителей.
Другой принцип говорит о том, что Methoden с одинаковыми именами могут иметь различные списки параметров (данных). - LabVIEW пока не позволяет реализовать.

Вообще, парадигм программирования много. Почему Вы упомянули только эти две?

Вы имеете в виду ООП и традиционный метод программирования? Если да. То по простой причине - различия наиболее наглядны.

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

Таблицу подправил.
Конструктивная критика принимается охотно. :о)

Igor_G писал(а):ОК. Я почему тогда С++ оперирует только с термином ООП?

Это чисто терминологическое различие. В С++ есть только 1 средство поддержки ООП. Если угодно, можно говорить о "средствах поддержки ООП" в С++ (т.е. этот самый "++"), которые занимают то же место, что и LVOOP в .

Но программировать ООП можно и без встроенных средств поддержки. Typedef вместо класса, Кластер вместо объекта и немного самодисциплины.

Igor_G писал(а): пока LabVIEW поддерживает только один из принципов Polymorphismus. Т.е. тот, что разрешает Классам Детей переписывать функции Классов Родителей.
Другой принцип говорит о том, что Methoden с одинаковыми именами могут иметь различные списки параметров (данных). - LabVIEW пока не позволяет реализовать.

Полиморфизмов, вообще много.
Статический полиморфизм в виде shadowing реализован не будет, видимо, никогда http://zone.ni.com/devzone/cda/tut/p/id/3574
но и нужен ли он?
Одну из последних дискуссий по теме c участием Stephen Mercer можно найти здесь:
http://forums.ni.com/t5/LabVIEW-Idea-Ex ... 498#M15036

Но программировать ООП можно и без встроенных средств поддержки. Typedef вместо класса, Кластер вместо объекта и немного самодисциплины.

Ооо... В 2005 или 2006 на LabVIEW 7.1.1 я начинал один большой проект как OOP (тогда еще не было поддержки OOP LabVIEW).
К сожелению шеф помер (очень хороший человек был) и проект закрыли. Много тогда сделать не успел. Но очень хорошо помню, как трудно было.
Три последних года я на LabVIEW вообще ни чего не делал (и много конечно забыл ;о). Но еще могу сравнить LabVIEW 7.1 и 2011. То что сейчас предлагает LabVIEW 2011 этоже совсем др. дело!
Нет. Уж если OOP то только с LVOOP. Пока на уровне вспоминания (игр c) LabVIEW мне LVOOP очень нравиться.
Хотя каждый конечно решает сам.

Для 7 можно использовать GOOP. Я на седьмой версии пользовался таким вот самодельным ООП: typedef, кластер, параметр, отвечающий за тип.
Новый ОО проект в 2011, конечно только LVOOP.

Не могу разобраться в настройках иерархии класса (наследование).

За что отвечают пункты:

Transfer all Must Override requirements to descendant classes — Place a checkmark in this checkbox to allow the class to transfer all override requirements to any descendant classes instead of overriding the dynamic dispatch VI itself. You also can use the Transfer Must Overrides? property to transfer all override requirements to descendant classes programmatically.

Data Value References - Restrictions on New and Delete—Includes the following components:

Restrict references of this class type to member VIs of this class — Allows only member VIs of this class to create data value references to members of this class.

Restrict references of descendant class types to member VIs of this class — Allows only member VIs of this class to create data value references to any descendants of this class.

За что отвечают пункты:
- Restrict references of this class type to member VIs of this class — Allows only member VIs of this class to create data value references to members of this class.
- Restrict references of descendant class types to member VIs of this class — Allows only member VIs of this class to create data value references to any descendants of this class.

Согласен. Вопрос очень интересный.
Что это такое прочитать можно здесь:
http://zone.ni.com/reference/en-XX/help ... reference/
Штука интересная, но как ей пользоваться пока ума не приложу. Поэтому пока все галочки там снимаю.
Простенький примерчик бы не помешал ;о)


У меня вопрос по проще:
как можно получить доступ на данные из одного child класса в др. child классе (Parent класс общий). То что это возможно, читал. Может кто знает?

Все эти навороты могут помочь при реализации некоторых design patterns. Настоятельно рекомендую документы из этого списка: http://labviewportal.org/viewtopic.php?f=23&t=3010

FireFly писал(а):За что отвечают пункты:Transfer all Must Override requirements to descendant classes

Которые override из базового класса, помеченные как "must override" передадут эти требования своим дочерним классам.

FireFly писал(а): Restrict references of this class type to member VIs of this class

Помогает реализовывать, например, singleton через DVR.

FireFly писал(а):Restrict references of descendant class types to member VIs of this class

то же но для всей иерархии.

Igor_G писал(а): как можно получить доступ на данные из одного child класса в др. child классе (Parent класс общий). То что это возможно, читал. Может кто знает?

В принципе можно объявить 1 класс другом (Friend) другого. Зачастую, необходимость объявления friends означает нерациональное проектирование Вашей иерархии.

mzu2006 писал(а):

Igor_G писал(а): как можно получить доступ на данные из одного child класса в др. child классе (Parent класс общий). То что это возможно, читал. Может кто знает?

В принципе можно объявить 1 класс другом (Friend) другого. Зачастую, необходимость объявления friends означает нерациональное проектирование Вашей иерархии.

Да.
Объявление др. класса Friend явл. на мой взгляд тоже признаком не продуманности структуры классов. (Хотя иногда эта возможность может быть, как изключение очень даже кстати).
На сколько я понял назначить Friend можно класс(ы) и/или какую то часть класса(ов) из совсем другой классовой структуры (например класс самокат называет своим другом класс самовар).
Кстати.
А какие конкретно возможности имеет класс и/или его часть со статусом Friend на уровне доступа к данным и использования функций? (Не могу ни чего внятно-вразумительного найти).

Назад к моему вопросу.
Я спрашивал о другом.
НАПРИМЕР: (пример выдуманый, но он должен объяснить смысыл моего вопроса).
Есть класс родителя "измерительный прибор" с одной функцией измерять и с одним элементом шкала (например тип DBL). У него появляются два класса детей "амперметр" и "вольтметр". Классы детей не имеют свой собственной функции измерять, т.к. они ее наследовали от класса родителя "измерительный прибор", тоже самое произошло с элементом шкала. У классов детей добавилась только функция подключения параллельно или последовательно и новые свойства элемента шкала A и V (т.е. тип стал String). До этого момента все легко и просто.
Теперь у класса родителя "измерительный прибор" появляется новый ребенок "ваттметр". Он также наследует функцию предка измерять и элемент шкала. Родственные отношения у него с др. 2 классами детей - родные брат и сестра. Новой функции класса "ваттметр" "вычислить мощность" надо получить доступ к данным классов "амперметр" и "вольтметр" и произвести умножение.
Теперь вопрос. Как это сделать? Функция "вычислить мощность" просто так не получает разрешение на доступ к данным своих братьев.
Уверен, что решение этой маленькой проблемы должно быть очень простое.

P.S. Какие ограничения на уровне доступа есть между классами родных братьев (default)? И где их можно изменить?

Назад к моему вопросу.
Я спрашивал о другом.
НАПРИМЕР: (пример выдуманый, но он должен объяснить смысыл моего вопроса).
Есть класс родителя "измерительный прибор" с одной функцией измерять и с одним элементом шкала (например тип DBL). У него появляются два класса детей "амперметр" и "вольтметр". Классы детей не имеют свой собственной функции измерять, т.к. они ее наследовали от класса родителя "измерительный прибор", тоже самое произошло с элементом шкала. У классов детей добавилась только функция подключения параллельно или последовательно и новые свойства элемента шкала A и V (т.е. тип стал String). До этого момента все легко и просто.
Теперь у класса родителя "измерительный прибор" появляется новый ребенок "ваттметр". Он также наследует функцию предка измерять и элемент шкала. Родственные отношения у него с др. 2 классами детей - родные брат и сестра. Новой функции класса "ваттметр" "вычислить мощность" надо получить доступ к данным классов "амперметр" и "вольтметр" и произвести умножение.
Теперь вопрос. Как это сделать? Функция "вычислить мощность" просто так не получает разрешение на доступ к данным своих братьев.
Уверен, что решение этой маленькой проблемы должно быть очень простое.

P.S. Какие ограничения на уровне доступа есть между классами родных братьев (default)? И где их можно изменить?

Решение нашел. Проблема была в том, что слишком сложно думал.

Все решается просто. Через родительские функции доступа к данным (читать, писать) и дополнительный cluster class (т.е. сделал дополнительный ctl). Скриншоты думаю объяснят мое решение доступа на данные классов братьев ;о)

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

Наряду с основными постулатами ООП есть ряд соглашений (шаблонных ситуаций, паттернов дизайна) = design pattern - наработанных приемах применения основных постулатов. (ещё раз отсылаю к http://labviewportal.org/viewtopic.php?p=26182#p26182).

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

mzu2006 писал(а): ...Например, если хочется соблюсти инкапсуляцию вольтметра и амперметра, то
почему не воспользоваться паттерном "включение", в котором класс ваттметр будет иметь 2 прибора члена класса: амперметр и вольтметр.

Где конкретно описывается принцип работы этого шаблона?

mzu2006 писал(а):наследование - это достаточно ограничивающий механизм.

??? Досиго момента считал, что наследование самый мощный инструмент OOP. А Encapsulation и Polymorphismus лишь сильные вспомогательные механизмы помогающие идеально реализовать наследование.