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?

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

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

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