CodeSys. ООП. Свойства

Наткнулся в интернете.

Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.

©Википедия. 21 век н.э.

Методология у нас включает объекты, ну а мы в промышленном программировании оперируем объектами. Каждый является экземпляром класса, что наталкивает нас на мысль, что функциональный блок — это «класс». И остается иерархия наследования… С чем, в большинстве случаев очень проблематично. Ибо наследование не наш конек)

Но товарищи из CodeSys, вроде как с этим помогают.

Четрые основные кита, на которых строится ООП:

1. Абстракция
2. Инкапсуляция
3. Наследование
4. Полиморфизм

И Codesys своим расширением стандарта IEC 61131-3 позволяет немного поиграться с этим.

Объект «Свойства»

Определение

Свойства — это расширение стандарта IEC 61131-3 и инструмент для объектно-ориентированного программирования.

Свойства используются для инкапсуляции данных, поскольку они обеспечивают внешний доступ к данным и одновременно действуют как фильтры. Для этой цели свойство предоставляет методы доступа Get и Set, которые обеспечивают доступ для чтения и записи данных экземпляра.

«Свойства» могут быть добавлены к Программе, Функциональному блоку или блоку глобальных переменных.

Создание «Свойства»

Для создания кликаем ПКМ на нужном нам файле и выбираем «Добавление объекта» ---> «Свойства»

После это операции нам откроется окно настроек свойства.

Окно настроек объекта «Свойство»

Имя, Тип возвращаемого значения и язык реализации, надеюсь, всем понятные поля. Мякотка тут это «Спецификатор доступа».

Спецификаторы доступа

• Public — доступ без ограничений.
• Private — доступ ограничен программой, функциональным блоком или глобальным блоком данных.
• Protected — доступ ограничен программой, функциональным блоком или глобальным блоком данных и объектами, которые будут от них унаследованны.
• Internal — доступ ограничен пространством имен, библиотекой.

Сегодня мы постараемся разобрать все кроме INTERNAL, так как там очень много надо понять до.

ПРАКТИЧЕСКАЯ ЧАСТЬ

И так вот и начинается наша фантазия. Для чего же нам нужны эти свойства, как работать с ними и так далее…

Доступ к переменным блока VAR

И так приступим… Создадим какой-нибудь функциональный блок, условно это будет главный объект, над которым мы и будем производит наши действия.

И добавим к нашему ФБ ряд переменных. Name, какой-нибудь ID и условно уставку.

Виски 1967 года купить на сайте www.cognac-whisky.ru.

Теперь создаем экземпляр данного функционального блока, сразу в программе.

А теперь присваиваем значения нашим переменным из тела программы.

Записываем переменные в теле PLC_PRG

После компиляции смотрим список ошибок.

Как бы понятно, что это не Input, не IN_OUT, но если я очень хочу? Вот тогда нам на помощь приходят свойства.

Начнем с имени.

Если не указывает модификатор доступа, то считай это PUBLIC.

После того как добавили у нас под блоком появляется его свойство и два метода Get (Взять значение свойства) и Set (Установить значение)

Начнем с установки значения - Set

Открываем в редакторе и пишем что sName:=Name; а в методе Get наоборот.

Теперь можно проверить в действии. Пока все лишнее отправляем в комменты.

И вот что у нас выходит. Теперь немного про логику работы.

Методы GET и SET работают в зависимости от того в какой стороне от знака присваивания стоит Свойство. Если слева, то мы присваиваем значение, а если справа то просим вернуть значение.

Теперь пойдем дальше по модификаторам доступа.

Следующий будет у нас свойство с именем ID

Теперь оно прям защищенное защищенное, но возникает кое какой нюанс. (Быстро пропишем Get и Set)

И так же указываем в цикле программы.

Компиляция нам даст ошибки!!!

И поступит информация, что нельзя достучаться до защищенного свойства. Доступ к нему есть только из самого функционального блока.

Посмотрите на скриншот выше. Вы догадываетесь какое будет значение в поле iID?

Правильно никакое, так как у нас данный функциональный блок еще не исполняется в цикле программы.

поплавковый фланцевый конденсатоотводчик. Лечение зависимости гипнозом и еще.

Но если мы все пропишем, то это одинаковые конструкции.

Тут еще одна конструкция.

Но зачем тогда нам нужен защищенный модификатор?

Чтобы скрыть наших полей для внутреннего использования. Хотя мы к ним можем обращаться и так. Единственное, что GET и SET могут дополнительно совершить необходимые действия над полями. Ну и там наследование еще, там типо красиво должно быть…

Представим ситуацию, что ID задается пользователем. Как ему душе угодно, а вот адрес мы выдаем на основании этого ID, но реализация этого чуда скрыта. Перепишем немного исходный код.

ID больше не Protected, а паблик и мы задаем какое-нибудь значение.

Вполне хорошая тема. А теперь нам надо получить адрес на выходе

Вот так у нас считается этот адрес. Давайте запустим и глянем что в итоге.

Ну вот Адрес 204, а теперь мы возьмем другой объект, который будет унаследован он нашего MainObject

Наш новый экземпляр

Как можно заметить функциональный блок чист, но так ли это? Создаем экземпляр и смотрим.

Прекрасно работает… У нас есть нужные поля и свойства, хотя в реализации пусто, но что мы видим… OUT равен 0, так как реализация не наследуется. А теперь упакуем реализацию. Идем в родительский класс, у нас он MainObject, и там делаем protected свойство с адресом.

И прописываем эту строчку в родительском классе и у наследника.

И мы получаем одинаковые адреса. Если мы изменим алгоритм у родителя, то он меняется и у наследника.

А теперь я хочу переписать свойство… и в класс FirstLevelObject я опять создаю свойство OutAdr.

И немного меняю реализацию. Прибавляю в конце 5, а не 4. Иииии…

Увы и ах, но так нельзя. Мы не можем переписать Protected методы. А public?

А паблики вполне можно переписывать. Ну вот в целом и небольшая работа с объектами «Свойства»

Пост от Александра Судалина.

Первоисточник на ЯндексДзене.