ООП: plcopen-oop-boiler-demo project где - бы посмотреть ?

[dorofeevms]

Всем привет!
Давно меня мучает вопрос: где бы найти plcopen-oop-boiler-demo ?
Сей проект любезно упомянут в https://ftp.owen.ru/CoDeSys3/98_Book....99_rfc_ru.pdf
Так же и в других местах нет-нет да и всплывут ссылки.
Возможно, я загоняюсь в дебри. Но очень мне нравятся идеи ООП применительно к контроллерам. Некий подобный подход я давно
мучительно пытаюсь использовать в среде CDS2.3. Там костылей и ограничений больше, но есть неумираующие проекты в этой среде.
Да и вообще любопытно посмотреть, ибо ссылки НИГДЕ не ведут к самому проекту.

Ну и если кто-либо может поделиться интересными ссылками на литературу и примеры из этой области - буду Очень признателен.

DMS

[Евгений Кислов]

Всем привет!
Давно меня мучает вопрос: где бы найти plcopen-oop-boiler-demo ?
Сей проект любезно упомянут в https://ftp.owen.ru/CoDeSys3/98_Book....99_rfc_ru.pdf
Так же и в других местах нет-нет да и всплывут ссылки.
Возможно, я загоняюсь в дебри. Но очень мне нравятся идеи ООП применительно к контроллерам. Некий подобный подход я давно
мучительно пытаюсь использовать в среде CDS2.3. Там костылей и ограничений больше, но есть неумираующие проекты в этой среде.
Да и вообще любопытно посмотреть, ибо ссылки НИГДЕ не ведут к самому проекту.

Ну и если кто-либо может поделиться интересными ссылками на литературу и примеры из этой области - буду Очень признателен.

DMS

Добрый день.
Ссылка на упомянутый вами проект:
https://www.plcopen.org/download_fil...791b367a7/342/

[Забодай тебя комар]

Не могу привыкнуть к стилю изложения, принятому в "западной" литературе... Поэтому замеченные мною "нюансики" ООП в CODESYS, возможно, давно описаны (да мной не прочитано) и являются нормой, но я был неприятно удивлен:

1. Нет нормального механизма скрытия методов и т.п. атибут 'hide' просто исключает нечто из упоминания, но вовсе не запрещает к этому нечто доступ. Логичнее было бы "не видишь - значит, недоступно вообще".
2. Блок-наследник должен явно вызывать блок-родитель! Мне это представляется крайне нелогичным: для того, чтобы вызвать виртуальные (т.е. перепоределенные в наследнике) методы, надо явно вызвать SUPER^(), т.е. своего предка, в "теле" блока!

Но в остальном терпимо...

[Валенок]

Не могу привыкнуть к стилю изложения, принятому в "западной" литературе... Поэтому замеченные мною "нюансики" ООП в CODESYS, возможно, давно описаны (да мной не прочитано) и являются нормой, но я был неприятно удивлен:

1. Нет нормального механизма скрытия методов и т.п. атибут 'hide' просто исключает нечто из упоминания, но вовсе не запрещает к этому нечто доступ. Логичнее было бы "не видишь - значит, недоступно вообще".
2. Блок-наследник должен явно вызывать блок-родитель! Мне это представляется крайне нелогичным: для того, чтобы вызвать виртуальные (т.е. перепоределенные в наследнике) методы, надо явно вызвать SUPER^(), т.е. своего предка, в "теле" блока!

Но в остальном терпимо...

В чем нелогичность п. 2?

[Забодай тебя комар]

В чем нелогичность п. 2?

ООП подразумевает, что НЕпереопределенные методы вызываются такими, как есть. Метод "тела блока", в наследнике я явно не переопределяю, следовательно, должен выполняться метод предка.

В CODESYS реализовали блок так, что "тело" не имеет явного метода, и тогда получается, что объявляя наследника я автоматически переопределяю его тело...

[Валенок]

ООП подразумевает, что НЕпереопределенные методы..

1.ООП НЕподразумевает [обязательное наличие] "дефолтного" метода (типа тела ФБ)
2.МЭК подразумевает наличие ФБ, которое вызывается как ЭкземплярФБ(..)

..В CODESYS реализовали блок так, что "тело" не имеет явного метода...

Да. Выше. И самое главное - перед КДС3 были 2.3, 2 - и там есть вызов как ЭкземплярФБ(..). С какого это должно пропасть в КДС3? Потому что что-то кому-то там непонравилось?

Хотите "чистоты" ООП? Дык все просто как 2*2 - НЕ используйте этот дефолт. Исполнение в виде:

;

решит Ваши (и только Ваши) проблемы