caxapa.ru :: Был аналогичный случай. Контроллер насосной станции. Пусковая аппаратура, непосредсвенно крутящая двигатели, может использоваться разная. В итоге 17 классов, реализующих взаимодействие с очень разными частотниками, устройствами плавного пуска и разными вариантами схем на контакторах и основной алгоритм, которому можно подсунуть любые объекты этих классов в любом разумном сочетании.

AlexG (19.05.2024 05:09, просмотров: 304) ответил POV на Полиморфизм пришлось к месту в столь нишевой железячной задаче?!...

Был аналогичный случай. Контроллер насосной станции. Пусковая аппаратура, непосредсвенно крутящая двигатели, может использоваться разная. В итоге 17 классов, реализующих взаимодействие с очень разными частотниками, устройствами плавного пуска и разными вариантами схем на контакторах и основной алгоритм, которому можно подсунуть любые объекты этих классов в любом разумном сочетании.

Протоколы обмена с внешним миром тоже по такому принципу - на каждый порт вешается класс, реализующий нужный протокол, а объекты протоколов которые не нужны даже не создаются.

Ответить

- Ребята, вы серьёзно? Я кагбэ этих насосных станций абы не сотню разных сделал, откуда 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)

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