Vitekkz88 писал(а):1.На минуточку, а у Вас в программах часто смешиваются два паттерна? Машина состояний и produce/consumer? И много машин состояний(10,20, сколько в пике было?).
Но Producer-Consumer и есть тоже стейт машина. Классический паттерн имеет цикл для генерации комманд (Producer), и второй цикл для их выполнения (Consumer). А Consumer как раз реализован как стейт машина? Хотя согласен, Consumer может и не содержать стейт-машины, но если Вы посылаете в него комманды, то это уже стейт машина.
Vitekkz88 писал(а):Про обработку ошибок: я их в отдельную очередь сгружаю все и поднимаю в отдельном потоке с subVI для которой как раз есть отдельный интерфейс. В чем неудобство иметь отдельную очередь для обработки ошибок с отдельным subVI?
Нет отдельной очереди на обработку ошибок. Посмотрите скрин, увидите, что я имел ввиду. Обработчик ошибок - уже часть цикла.
Vitekkz88 писал(а):2. Что значит копировать код? Я прекрасно справляюсь с созданием логически завершенных SubVI. И их проще сопровождать, документировать и допиливать. Это аккуратно оформленный код, всё как надо с комментариями. Взял и поставил, дел на 3 секунды. SubVI - это и есть метод некоторого класса.
Да, но если Вам нужно в библиотеке Б использовать цепочку из виаек библиотеки А, например, так (в порядке вызова):
VI1 - VI2 - VI3
и нужно изменить функционал VI2, как Вы поступите? Скопируете VI1, VI3 в либу Б, а вместо VI2 создадите новую? На "лету", динамически ведь не удастся заменить ее. А в случае ООП все просто - VI2, это dynamic dispatch виайка, которую дочерние классы просто могут переписать. И цепочка VI1 - VI2 - VI3 останется не тронутой для основной программы, ее функционал будет менятся динамически во время выполнения. Т.е. Вы изменяете код отдельных модулей, не трогая основной программы.
Это большое преимущество по сравнению с традиционным подходом, ведь в трад. подходе больше "завязанность" на интерфейсы виаек, входа-выходы. А в случае классов Вы работаете с интерфейсами. И тогда замена функционала происходит менее болезненно.
Vitekkz88 писал(а):3. Доступы к полям и методам класса как-то регламентируются в Actor-е? Как там с защитой полей?
Так же, как и везде. Если будет создан accessor, то к данным можно будет достучаться. А так - данные приватные, это уже дело разработчика, к чему создавать доступ. Повторюсь, актор - это класс, со всеми вытекающими.
Vitekkz88 писал(а):4. Вся эта история с Actor-ами переносится в Real-Time? И на сколько использование Actor-ов замедляет работоспособность программы в целом? Неужели нет проигрыша?
Да, переносится. Но есть одно но. Очередь, по которой акторы передают сообщения-команды, в 4 раза медленней стандартной очереди. Поэтому, если нужна быстрая коммуникация, в акторах есть понятие Helper Loop. Плюс ко всему, никто не запрещает использовать модули акторов с не-акторами.
Vitekkz88 писал(а):Про HAL не понял. Вообще про такое не слышал, если честно...простите
Пример: у меня в программе используется 5 разных типов оборудования(подключенных по USB, Ethernet). Для каждого устройства у меня отдельный поток взаимодействия. Где тут что абстрагировать? Они и так в отдельных потоках сидят и ждут своих команд или данные сливают в потоки обработки. Куда уж проще и понятней-то с точки зрения LabVIEW? Зачем для этого дела создавать отдельный класс и методы?
Советую загуглить "labview hardware abstraction layer". Вкратце. Сегодня заказчик сказал, что программа должна общаться с контроллером по TCP/IP, а завтра - через ком порт. Сегодня в качестве мультиметра используется NI железо, завтра - железо от Agilent. А значит, разные протоколы, разные драйвера. При помощи плагин архитектуры, в софте я использую общие, абстрактные методы для работы с железом, а во время рантайма определяю, какой плагин будет выполняться. Таким образом, можно проганять целую программу на симулируемом железе, а можно одним кликом переключить на реальное. Вот это и есть абстракция железа - софт использует абстрактные методы, а конкретную имплементацию Вы задаете такую, какую нужно.
Может я объясняю и путано, но тогда советую посмотреть презентации.
HAL в любых языках вещь полезная и нужная, тут даже нет никаких сомнений. Особенно, если нужно делать симуляцию железа - т.к. "живое" железо еще не готово/не собрано/не подключено, а программу в целом тестить надо. Что тогда - скипить участки кода? Кейс структуры?
Vitekkz88 писал(а):Kosist писал(а): Но, само собой, есть и минуса. Первое - при неправильной архитектуре в целом, можно здорово запутаться, и акторы будут лишь во вред, а не на благо.
Какой-то странный минус, если честно, он общего плана. При неверной архитектуре можно с любой технологией сесть в калошу
Меня интересуют более фундаментальные недостатки, к которым относится минус номер 2.
Тут согласен, неудачный пример.
Vitekkz88 писал(а):Да, Actor позволяет реализовать ООП, но опять же не дотягивает до других ООП(а в чем не дотягивает то? "отсылка" метода = + класс с 2 методами? в этом плане что ли?).
Не совсем. Например, в LV OOP отсутствует множественное наследование. Но не большая беда, т.к. в некоторых текстовых его тоже нету.
Тогда, скажем, в Python есть куча готовых методов типа __init__, __repr__, __call__, и т.д., которые доступны всем классам без исключения, и позволяют их переписать. В LV, "голый" класс не имеет родительских методов вообще. Уверен, что коллеги на портале, которые более опытные в текстовых языках, могут привести больше сравнений.