Комментарии 37
Я бы не назвал это ООП.
Это просто типичный способ упрощения работы дизайнеру алгоритма за счет того, что создается база данных сигналов под конкретный объект управления. Раньше это все писалось ручками и можно было легко сделать неуникальную переменную и получить проблемы.
Объекты — это часто физические компоненты — моторы, кнопки, задвижки и т.д и они импортируются из принципиальной схемы. Чтобы не возникало путаницы с сигналами, все эти объекты автоматически получают набор входных и выходных сигналов и параметров, которые имеют уникальные имена и которые потом кодогенератор может преобразовать в глобальные переменные. В этом и есть смысл базы данных сигналов. Никаких инкапсуляций, никаких классов, все направлено на то, чтобы скрипт, указанный в конце вашей статьи, сгенерировал нужный файл, в котором будут представлены все десятки тысяч сигналов, используемые в реально исполняемом коде.
Как верх стандартизации вы можете глянуть на IEC 61850, где четко прописано как все это дело должно работать.
Но то что это совсем не ООП не соглашусь. Например:
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере статьи КД1, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
А где здесь методы?
Насколько я знаю эти вещи, кроме пересчета — т.е. умножения/деления на константу + оффсет + ограничение по максимуму/минимум, эта база данных не делает. Т.е. любой сигнал, по умолчанию проходит через этот пересчет и вы, если хотите, можете привести милливольты в Цельсии или напряжение в Per Unit. Но это все!
ООП включает в себя три столпа: инкапсуляция, наследование, полиморфизм. Ниже я покажу как этих вещей можно добиться в С.
habr.com/ru/post/263547
Разница между современным C++ и C кажется огромной, но различия между этими языками не стоит преувеличивать. Приуменьшать, впрочем, тоже необязательно...)
Тем более, четкого и однозначно принятого определения ООП до сих пор нет.
С точки зрения пользователя СFront это ООП, а С — нет.
Интересное, кстати разделение, если делать X — удобно, то это парадигма ООП, а если неудобно — не ООП.
По поводу механизмов — наследование структур есть, структуры могут содержать указатели на функции, вспомним, например, STDIN / STDOUT. инкапсуляция в Си из коробки получше чем в современных языках — всё инкапсулировано и скрыто в одном файле, пока вы сами, явно, не опишите, что из этого файла можно будет использовать снаружи. *
С одним фактором по поводу удобства, конечно, соглашусь — полиморфизм стал действительно удобнее с развитием парадигмы. Но разве этим теперь определяется ключевое развитие между парадигмами, удобством использования одного подхода?
* Хоть четкого определения данной парадигмы нет, если полиморфизм и инкапсуляция довольно хорошие механизмы, и с развитием ООП/ООД они стали популярнее и удобнее, наследование отличительной чертой парадигмы я никак не могу назвать
«Я считал объекты чем-то вроде биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.»
«Мой опыт в математике заставил меня понять, что каждый объект может иметь несколько алгебр, они могут объединяться в семейства, и это может быть очень полезным.»
«Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды.»
«Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)»
«Я не против типов, но мне не знакома ни одна система типов, которая не вызывала бы боли. Так что мне все еще нравится динамическая типизация.» — Алан Кей за динамическую типизацию.
«ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.» — а наследования в Smalltalk не было вовсе.
На вход идет число — значение с датчика, на выход тоже число — команда упрвления, все число, даже если это логическое да или нет 0,1. Для упрощения можно считать что все числа — реальные двойной точности.
А «идеи возникшие позже», это разные схемы обработки этих чисел.
Ярко показывает степень разрыва в мышлении тот факт, что Алан Кей считает LISP «главной идеей в Computer Science», тогда как большинство преподавателей в вузах если и слышали это название, то ничего не понимают в функциональном программировании. И уж совершенно точно в вузах студенты не слышат ни слова про SOLID, про то, что наследование — очень опасная штука и её нужно использовать очень осторожно (о чём написано даже в «банде четырёх»). Там, блин, задают домашние задания на придумывание идиотских иерархий классов. Даже полиморфизм они зачастую неспособны объяснить без наследования.
Когда-то я жалел, что не закончил вуз по программистской специальности. Сейчас — не жалею. Я закончил лингвистический класс гимназии и (спасибо Наталье Михайловне) знаю английский достаточно хорошо, чтобы слушать и читать Роберта Мартина, Мартина Фаулера и пр. в оригинале, а не преподавателей российских вузов, многие из которых вообще ни разу в жизни не занимались профессиональным программированием и переписывают друг у друга из учебников и методичек одну и ту же ересь десятилетиями.
Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which can contain data, in the form of fields (often known as attributes), and code, in the form of procedures (often known as methods). A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»). In OOP, computer programs are designed by making them out of objects that interact with one another.[1][2] OOP languages are diverse, but the most popular ones are class-based, meaning that objects are instances of classes, which also determine their types.
en.wikipedia.org/wiki/Object-oriented_programming
инкапсуляция, наследование, полиморфизм – это не про ООП
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере КД, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
Но с точки зрения всех, кто впервые сталкивался эти этим абстракциями, после классических процедурных языков понятнее не становилось, кажется наоборот все еще больше запутывалось.Тут похоже опечатка. Но по сути ИМХО от процедурного Паскаля перйти к ОО Паскалю Delphi ( упомянутому в статье) очень просто даже на формальном уровне.
Простейшая инкапсуляция уже есть в записях (record). Далее понятие о наследовании приходит в таких простых примерах:
type
TCoord = record // координаты точки
x, y : integer
end;
TRect = record // прямоугольник
leftTop, RBot : TCoord;
end;
Остается заменить слово «record» на слово «class» (с указанием имени предка в скобках), разрешить записывать заголовки методов внутри таких «записей» и оговорить несложные правила полиморфизма классов.
только чистый Си, и еще желательно урезанный правилами и рекомендация MISRA C, чтобы все было надёжно, переносимо, безопасно.Тут мне видится историческая несправедливость и непоследовательность. Еще во времена виртовского Паскаля критики указывали на слишком сильную (по их мнению) типизацию, отмечая, что Си — гораздо более гибкий язык. Следовательно на Си возможно больше трюков и, как оборотная сторона монеты, больше ошибок, более трудная читаемость исходного кода. Паскаль был сделан для обучения, Си — для разработки. Логичнее было выбрать для АЭС Паскаль, как потенциально более простой и надежный.
Но с Си на контроллерах управления, мне кажется это исторически сложилась такая практика, контроллеры более слабые, чем десктопные процессоры, поэтому гибкость Си позволяла реализовать «всякие трюки», а потом в критических системах это осталось, типа работает — не трогай. Вчера сделали на Си работало значит и сегодня будем продолжать тоже.
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
В этом же стандарте есть понятие
Автоматизированная генерация кода (automated code generation): функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
Таким образом схему графического языка SimInTech вполне можно рассматривать как программу на проблемно ориентированном языке. (графическом языке программирования)
И еще, в IDE Delphi функции все таки нужно писать на Паскале. А в графическом языке — не надо, можно все нарисовать.
Логичнее было выбрать для АЭС Паскаль, как потенциально более простой и надежный.
Не для АЭС, но для автоматизации производственных процессов так и сделали. Для программирования ПЛК часто используют ST (IEC 61313-3), который очень похож на Паскаль.
Но при этом этот же ST компилируется перед выполнением и возможно одной из промежуточных форм опять таки является Си.
Обычно интересен язык на самом высоком уровне. На котором будет думать программист. Дальше программа интерпретируется, транспилируется, компилируется, линкуется, проходя множество представлений и в конце превращаясь в наборы нулей и единиц.
Вот, например, реальное описание в графической нотации алгоритма управления задвижками АЭС.:
Вячеслав, могу ли я попросить Вас подсказать, это что за стандарт описания алгоритмов? Или это своя росатомовская документация?
Это по сути внутренний стнадрат предприятий росатома, причем не всех. В основу, как я понимаю, взяты принципы из немецких гет-планов, в совое время Siemens продал свою старую технологию ВНИИА им. Духова, там были гет-станции специальные компьютеры, геде изображелись листы алгоритмов, слева вход справа выход между ними логика работы. Дале все это в рамке, с нумерацией листов подписями систем, и система кодирования ККS для имен сигналов. Получается такой вот документ, который все в росатоме понимают.
А может подскажете, как в серьёзной инженерной среде документируют ПО для ПЛК?
кроме как KKS (там всё по-немецки).
Или в большинстве случаев это просто текстовое описание?
По разному в разных организациях, да даже в одной и той же тоже может быть по разному. Так же зависит от цепочки разработки сколько учатников от проектной организации вних до наладке на объекте.
Вначеле всегда есть текст ТЗ, в котором есть или нет, картники.Вот на картинка скриншот из документа, это ворд с таблицами, для экономии они в одной таблицы и входы и выходы описывают. Так алогритм видит технолог у проектна и отдает его разработчику автоматики.
Они в свою очередь его перрисовывают, если там какой нибудь генподрядчик он вполне можт взять ворд и еще раз эти алгоритмы перерисвовать но уже в визио или архитект сьют совместив в одном проекте несколько систем.
Ну а конченый изготовитель всю эту радость рисует уже в среде разработки.
Если SimInTech использовать как например в кооперации для некоторых морских объектов, там от проектната до заливки в контроллер между организациями все в виде диаграмм алгоритмов SimInTech
Объектно ориентированное програмирование в графических языках