caxapa.ru :: Полиморфизм пришлось к месту в столь нишевой железячной задаче?!...

POV (18.05.2024 23:28, просмотров: 660) ответил Samx на Ну там было много датчиков разных типов и несколько регуляторов разных типов.

Полиморфизм пришлось к месту в столь нишевой железячной задаче?!...

Ну ввел класс ДАТЧИК у которого пара методов типа "прочитать ID девайса" и ещё пара абстрактных - которые должны быть реализованы в дочках.

И чё, всё? Чего наследники такого приобрели что это прям нужно?

Ответить

- Был аналогичный случай. Контроллер насосной станции. Пусковая аппаратура, непосредсвенно крутящая двигатели, может использоваться разная. В итоге 17 классов, реализующих взаимодействие с очень разными частотниками, устройствами плавного пуска и разными вариантами схем на контакторах и основной алгоритм, которому можно подсунуть любые объекты этих классов в любом разумном сочетании. AlexG(175 знак., 19.05.2024 05:09)
  - Ребята, вы серьёзно? Я кагбэ этих насосных станций абы не сотню разных сделал, откуда 17 классов?! Несколько раздельных процессов в биг-луп: несколько на опрос устройств, разного типа (по одному процессу на тип), таблица состояния в памяти, основной алгоритм и пара процессов на обмен данными по сети. Cкpипaч^пророк(323 знак., 19.05.2024 09:23)
    - 17 это, упрощенно, количество поддерживаемых типов частотников. Объекты, которые умеют управлять тем, что подключено именно к этому шкафу создаются по необходимости (в соответсвии с конфигурацией). Объекты всех 17 типов не существуют одновременно, хотябы потому что насосов максимум 4. - AlexG(19.05.2024 20:19)
      - В моей практике, конкретный тип частотника накладывает отпечаток на прикладной алгоритм управления. Дополнительные сигналы контроля, требующие обработки, различия в логике встроенных ПИД-регуляторов. Инкапсулировать - отсекать "избыточное" и ограничивать функционал. Но у каждого свои фломастеры, и свое чувство прекрасного. - Cкpипaч^пророк(19.05.2024 20:28)
        
        Вот этот весь отпечаток в классе и остается. Встроенные ПИДы не задействованы. Не то чтобы прям прекрасно получилось, но это позволяет не лезть в код при каждом заказе насосной станции. В, условно, прошлом поколении контроллеров и их ПО был жесткий расчет на конкретный частотник и конкретную конфигурацию станции и это был полнейший тупик с околонулевым повторным использованием прошивок и отладкой почти каждой станции на стенде с реальной водой и насосами. Некоторые AlexG(214 знак., 19.05.2024 21:05)
        
        Кот и лампа :( - Cкpипaч^пророк(19.05.2024 21:18)
        
        На всё упомянутое могу показать фото контроллеров, руководства по эксплуатации, страницы на сайте. Исходники - не могу. И испытания станций не фотографировались, насколько помню. - AlexG(20.05.2024 02:54)
        
        Просто рассказы ужасы невозможности построения модульных систем без ООП я слышал уже много раз. Они безпочвенны. Но как патерн проектирования - конечно имеет право на жизнь. С оговоркой - не единственно возможный. - Cкpипaч^пророк(20.05.2024 08:21)
        
        Кто говорит, что невозможно? Наоборот, умеренное (без фанатизма, я ж сказал) использование C++ даёт новые возможности, причём практически даром. Samx(377 знак., 20.05.2024 12:58)
        
        Я не утверждаю что это невозможно. Просто была такая задача и C++ для ее решения пригодился. - AlexG(20.05.2024 09:13)
        
        Вам на двоих один ответ - у меня претензии не к плюсам, как таковым, а к избыточной инкапсуляции. Схема "Модель-контроллер-вид", по моему опыту, лучше, ибо позволяет избежать "пустых абстракций", сохраняя и модульность, и возможность повторного использования кода. Cкpипaч^пророк(1 знак., 20.05.2024 16:28, ссылка)
        
        1. Не понятно, как вы из существования классов, реализующих унифицированную работу с какой-то внешней аппаратурой пришли к выводу об избыточной инкапсуляции. Я ведь не дал больше никаких деталей. Предлагаете разбить это на модель контроллер и вид? А зачем? Оператор вообще не работает с такой сущностью как "частотник"/"пусковая аппаратура". Да и пользовательский интерфейс тут не самая важная часть. Это автоматика, она большую часть времени без присутствия чаловека работает. 2. AlexG(648 знак., 20.05.2024 20:34)
        
        Спасибо за вопросы :) Cкpипaч^пророк(2755 знак., 20.05.2024 22:18)
        
        > в MVC модели приложения > "Controller" - более-менее очевиден. — И насколько очевиден? Что в контроллере? Какой функционал? Что он делает? - RxTx(30.05.2024 15:25)
        
        Прикладной алгоритм управления. Мы вообще-то о программировании насосных станций говорили. - Cкpипaч^пророк(01.06.2024 12:41)
        
        Уже спрашивал когдато, еще попробую. Можешь в приложении к сишечке ссылок полезных подкинуть? - Andreas(20.05.2024 16:31)
        
        У меня кроме Кернигана-Ричи ничео нет. Все остальное "музыкой навеяло" (я вообще на Паскале пишу, просто компилятором Си компилирую). - Cкpипaч^пророк(20.05.2024 17:06)
        
        Как это?!(про указанное в скобках) "даже используя си можно писать на бейсике"? Или компиляция в промежуточный код на си? (вроде фрипаскаль умеет) - Dingo(21.05.2024 05:35)
        
        Например, не использовать присвоения внутри вычислений условия в if. Отказаться от всех фишек Си (и Плюсов), отсутствующих в Паскале. Разница языков программирования вовсе не в скобках {} вместо begin end. - Cкpипaч^пророк(21.05.2024 16:45)
        
        Это я понимаю. Взять ту же строгую типизацию: gcc можно попросить через командную строку. Но я вот паскаль не на таком уровне уровне знаю, чтобы ограничивать себя самостоятельно. PS: А циклы тоже только с шагом в 1 используете? - Dingo(22.05.2024 05:17)
        
        Не настолько :) Cкpипaч^пророк(67 знак., 22.05.2024 07:59)
        
        Программу на паскале можно написать на любом языке. Вопрос методики и самоконтроля. - =AlexD=(21.05.2024 08:28)
        
        Согласно первоисточнику "... закоренелый настоящий программист может написать фортрановскую программу на любом языке." Однажды я собственными глазами видел такое чудо. Это была программа на Паскале, в ней был раздел объявления меток и были те метки с именами от lbl01 до lbl99 почти без пропусков :))) - ЫЫyкпy(21.05.2024 09:22)
        
        Переиначивать эту цитату можно как угодно, потому что она не о языках, а о методологиях проектирования. - =AlexD=(21.05.2024 10:13)
        
        Именно. Вплоть до банального - в отдельном файле объявляется некий тип данных (структура и указатель на нее) и все функции из этого файла принимают первым параметром такой указатель, что-то делая вокруг этой сущности. Чем это от класса и методов отличается? - да ничем, по сути. Cкpипaч^пророк(233 знак., 21.05.2024 16:46)
        
        Знаем мы эту методологию. "Я на асме/фортране/васике кодил, всё получалось, и сейчас получится, вы меня своим паскалем не соблазните!" :-) - SciFi(21.05.2024 10:41)
        
        дык так и писал. и чо. станки по сей день летают. правда чуть ниже обычного. - Alex68(21.05.2024 22:53)
        
        Фиг с ней, с нумерацией. Программа работала? :-) - SciFi(21.05.2024 09:28)
        
        Работала. Делала что-то с графами, для поиска оптимального размещения компонентов на печатной плате. ЫЫyкпy(61 знак., 21.05.2024 09:48)
      - Несколько лет назад (каждые пару лет?) мы тут обсуждали статью о вреде инкапсуляции данных. Склонен считать, что сама по себе инкапсуляция неплоха, но она подталкивает программиста к созданию "пустых слоев" абстракции. А это уже инфернальное зло. - Cкpипaч^пророк(19.05.2024 20:24)
        
        Много лет назад я написал код на С. Всё было понятно. Потом решил переписать код на С++ с несколькими уровнями наследования и виртуальными методами, чтобы было ещё понятнее. И теперь в этом коде я ничего не могу понять. Ale3000(204 знак., 20.05.2024 04:35)
        
        Да. Только мне регулярно приходится выдерживать баталии против молодый-амбициозных. Cкpипaч^пророк(513 знак., 20.05.2024 08:30)
- 1. Ввел класс TGeneralSensor. Samx(512 знак., 19.05.2024 00:14)
  - это ж надо так извратиться:) - Vit(19.05.2024 09:38)
    - Почему извратиться? Наоборот, самый прямой путь - для чего это всё в С++ и придумано. Ну вот вам другой канонический пример: Samx(402 знак., 19.05.2024 20:34)
      - это другое:) вот возьмите дуину - там есть setup и loop. это похоже на старт (с какой-то инициализацией и т.п.) и бесконечный процесс, который по сути таки перезапускаемый набор операций. так вот у процесса с идеологией run-to-complete (см. Quantum Leaps), т.е. конечный автомат (finite state machine), котрый торчит из вашего doStep() есть множество сходных названий, и, КМК, это скорее задача (task). вы соорудили примитивный диспетчер, но собственно задачи запихали по-глубже Vit(1204 знак., 19.05.2024 21:19)
        
        Ну да, я же так и сказал - всё, что на C++ делается просто и прозрачно, можно сделать руками на C, и при этом не получить ничего, кроме потерянного времени. Samx(106 знак., 20.05.2024 01:27)
        
        я вам объяснил, почему считаю конкретный случай извратом, в котором ещё и сами плюсы притянуты за уши, делая код абсолютно непрозрачным. вместо сервиса-спулера вы рожаете негибкое решение в виде массива с удивительными глубинами. насчет больше и дольше - ваши фантазии. вопрос не по примененному языку, а по архитектуре - там где-то в консерватории бардак. и звените - Vit(20.05.2024 10:06)
      - Т.е ужэ имея готовый набор функций 1-вире, вместо sendByte1Wire(data), вы (условно) пользуете SendByteIIC(data)? Нахуя, а главное, зачем? - mse homjak(19.05.2024 20:54)
        
        Наоборот - уже имея отлаженный код работы с I2C-датчиком, я просто заменяю обращение к члену класса TI2CSoft на обращение к его наследнику TI2CSoftBy1wire Samx(283 знак., 20.05.2024 12:13)
        
        Это понятно. Просто вам полюбому нужно всё написать ручками. Только у условного меня, на Ц, будет либо переназначение дефайнов, либо просто две функции, где это уже будет сделано прям в коде. - mse homjak(20.05.2024 12:45)
        
        Да, и в каждый вызов функции нужно будет явно передавать структуру с переменными состояния. Датчиков то несколько десятков. И для чего этот геморрой? Samx(117 знак., 20.05.2024 13:04)
        
        Да я, собсно, не против. mse homjak(665 знак., 23.05.2024 22:22)
        
        Возможно, вы не поняли. В этом случае, через существующую линию 1wire, на дальнем конце, с помощью расширителя портов 1wire, реализован I²C для опроса удалённого I²C-устройства через имеющуюся 1wire-сеть. - Nikolay_Po(19.05.2024 21:06)
        
        Это, как раз, понятно. Я не детализированно обозвал функции. типа setStartIIC() и setStart1wire(). Ну и набор вверх до записи-чтения. Т.е. это всё уже должно быть написано. Но вызов сделан не как написал я выше, а как принято в ЦПП. Дажэ не так mse homjak(578 знак., 19.05.2024 21:33 - 20.05.2024 12:48)
        
        Как-то делал девайс с несколькими SPI на STM, ну и в нём заюзал LWIP. Его отлаживать без дебажного выхлопа неинтересно было, ну и пришлось заюзать ногу SWO, а оно пересекалось с одним из SPI и подходящих свободных не было. Сделал SPI ногодрыгом, но выделил указатель SPI-ного типа на какую-то левую память для SPIn и не менял API и уже написанный код. - Vit(19.05.2024 22:01)
        
        Так в том и дело, заработало и хрен с ним. Эти механизьмы дают лютый выхлоп в некой стандартной среде, на неком стандартном оборудовании. Причом, чтобы низкий уровень ужэ кто-то написал. Тогда, да, пусть лошадь думает, у неё голова большая. А так, автоматика: нажал на кнопку, мешок на спине. Нажал другую, спина в мыле. Ну, мож кому-то, действительно, помогает, ХЗ. - mse homjak(19.05.2024 22:02)
    - Спасибо. Я уже было подумал что сам свихнулся :) - Cкpипaч^пророк(19.05.2024 09:52)

Микроконтроллеры