AlexG (19.05.2024 20:19, просмотров: 87) ответил Cкpипaч на Ребята, вы серьёзно? Я кагбэ этих насосных станций абы не сотню
разных сделал, откуда 17 классов?! Несколько раздельных процессов в
биг-луп: несколько на опрос устройств, разного типа (по одному
процессу на тип), таблица состояния в памяти, основной алгоритм и
пара процессов на обмен данными по сети.-
- В моей практике, конкретный тип частотника накладывает отпечаток на
прикладной алгоритм управления. Дополнительные сигналы контроля,
требующие обработки, различия в логике встроенных ПИД-регуляторов.
Инкапсулировать - отсекать "избыточное" и ограничивать функционал.
Но у каждого свои фломастеры, и свое чувство прекрасного. - 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)
- Уже спрашивал когдато, еще попробую. Можешь в приложении к сишечке
ссылок полезных подкинуть? - 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)
- Это я понимаю. Взять ту же строгую типизацию: gcc можно попросить
через командную строку. Но я вот паскаль не на таком уровне уровне
знаю, чтобы ограничивать себя самостоятельно. PS: А циклы тоже
только с шагом в 1 используете? - Dingo(22.05.2024 05:17)
- Программу на паскале можно написать на любом языке. Вопрос методики
и самоконтроля. - =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)
- Переиначивать эту цитату можно как угодно, потому что она не о
языках, а о методологиях проектирования. - =AlexD=(21.05.2024 10:13)
- Согласно первоисточнику "... закоренелый настоящий программист
может написать фортрановскую программу на любом языке." Однажды я
собственными глазами видел такое чудо. Это была программа на
Паскале, в ней был раздел объявления меток и были те метки с
именами от lbl01 до lbl99 почти без пропусков :))) - ЫЫyкпy(21.05.2024 09:22)
- Например, не использовать присвоения внутри вычислений условия в
if. Отказаться от всех фишек Си (и Плюсов), отсутствующих в
Паскале. Разница языков программирования вовсе не в скобках {}
вместо begin end. - Cкpипaч(21.05.2024 16:45)
- Как это?!(про указанное в скобках) "даже используя си можно писать
на бейсике"? Или компиляция в промежуточный код на си? (вроде
фрипаскаль умеет) - Dingo(21.05.2024 05:35)
- У меня кроме Кернигана-Ричи ничео нет. Все остальное "музыкой
навеяло" (я вообще на Паскале пишу, просто компилятором Си
компилирую). - Cкpипaч(20.05.2024 17:06)
- 1. Не понятно, как вы из существования классов, реализующих
унифицированную работу с какой-то внешней аппаратурой пришли к
выводу об избыточной инкапсуляции. Я ведь не дал больше никаких
деталей. Предлагаете разбить это на модель контроллер и вид? А
зачем? Оператор вообще не работает с такой сущностью как
"частотник"/"пусковая аппаратура". Да и пользовательский интерфейс
тут не самая важная часть. Это автоматика, она большую часть
времени без присутствия чаловека работает. 2. AlexG(648 знак., 20.05.2024 20:34)
- Вам на двоих один ответ - у меня претензии не к плюсам, как
таковым, а к избыточной инкапсуляции. Схема
"Модель-контроллер-вид", по моему опыту, лучше, ибо позволяет
избежать "пустых абстракций", сохраняя и модульность, и возможность
повторного использования кода. Cкpипaч(1 знак., 20.05.2024 16:28, ссылка)
- Просто рассказы ужасы невозможности построения модульных систем без
ООП я слышал уже много раз. Они безпочвенны. Но как патерн
проектирования - конечно имеет право на жизнь. С оговоркой - не
единственно возможный. - Cкpипaч(20.05.2024 08:21)
- На всё упомянутое могу показать фото контроллеров, руководства по
эксплуатации, страницы на сайте. Исходники - не могу. И испытания
станций не фотографировались, насколько помню. - AlexG(20.05.2024 02:54)
- Кот и лампа :( - Cкpипaч(19.05.2024 21:18)
- Вот этот весь отпечаток в классе и остается. Встроенные ПИДы не
задействованы. Не то чтобы прям прекрасно получилось, но это
позволяет не лезть в код при каждом заказе насосной станции. В,
условно, прошлом поколении контроллеров и их ПО был жесткий расчет
на конкретный частотник и конкретную конфигурацию станции и это был
полнейший тупик с околонулевым повторным использованием прошивок и
отладкой почти каждой станции на стенде с реальной водой и
насосами. Некоторые AlexG(214 знак., 19.05.2024 21:05)
- Несколько лет назад (каждые пару лет?) мы тут обсуждали статью о
вреде инкапсуляции данных. Склонен считать, что сама по себе
инкапсуляция неплоха, но она подталкивает программиста к созданию
"пустых слоев" абстракции. А это уже инфернальное зло. - Cкpипaч(19.05.2024 20:24)
- Много лет назад я написал код на С. Всё было понятно. Потом решил
переписать код на С++ с несколькими уровнями наследования и
виртуальными методами, чтобы было ещё понятнее. И теперь в этом
коде я ничего не могу понять. Ale3000(204 знак., 20.05.2024 04:35)
- Да. Только мне регулярно приходится выдерживать баталии против молодый-амбициозных. Cкpипaч(513 знак., 20.05.2024 08:30)
- Много лет назад я написал код на С. Всё было понятно. Потом решил
переписать код на С++ с несколькими уровнями наследования и
виртуальными методами, чтобы было ещё понятнее. И теперь в этом
коде я ничего не могу понять. Ale3000(204 знак., 20.05.2024 04:35)
- В моей практике, конкретный тип частотника накладывает отпечаток на
прикладной алгоритм управления. Дополнительные сигналы контроля,
требующие обработки, различия в логике встроенных ПИД-регуляторов.
Инкапсулировать - отсекать "избыточное" и ограничивать функционал.
Но у каждого свои фломастеры, и свое чувство прекрасного. - Cкpипaч(19.05.2024 20:28)