Написание кода при ООП, отличается при обычном процедурном программировании. Существует определенные принципы дизайна кода, которые позволяют создавать легко сопровождаемый, удобочитаемый, массово применяемый код - это SOLID. Эти принципы относятся к дизайну ваших модулей, а в нашем случае функциональных блок и функций в среде Codesys.
Первым делом стоит разобраться в функциях, хоть это и не относится к принципу единственной ответственности, но это очень важно для написания программы, - "Что должна делать функция?". Ответ на этот вопрос раз и навсегда убьет любые споры о том как правильно писать функции, а если их и писать, то максимально понятно.
А основным блюдом мы разберемся с принципами единственной ответственности для функциональных блоков, узнаем кто такие акторы и сколько их надо чтобы поменять код.
Функция
Функция - фрагмент программного кода, который можно вызывать из другого места программы. Метод класса - подходит вполне под определение функции, чем он и является. Так что для начала нам стоит научиться разбивать огромные портянки внутри функциональных блоков на простые методы, которые легче писать и проще сопровождать. Так как я пишу огромные полотна внутри функционального блока, не разбивая на функции, то давайте взглянем.
Я надеюсь, что вам плохо видно скриншот, но можно заметить, что у меня есть целый ряд условий, которые что-то делают, а именно взводят сигналы аварийные и предупредительные сигналы. И я предлагаю данную простыню поделить на функции, а теперь вопрос.
Что же должна делать функция?
Функция должна делать что-то одно и делать это хорошо.
И вот теперь запасаясь этим начинаем рефакторить(громкое слово, но уху приятно).Немного подумав я решил, что методы нам тут не товарищи, а вот свойства подходят идеально, а так как свойства организуют нам доступ до полей класса через функции get и set, то они нам помогли.
За место кучи ифов у нас вышло 4 свойства isTemperatureH. isTemperatureHH, isFlowL и isFlowLL. В каждый из этих свойств мы запихнули логику, которая раньше была прям в теле функционального блока. А правильность работы мы узнаем после тестирования.
Но суть в том, что функция get, свойства, например, isTemperatureH занимается лишь тем, что выдает нам предупредительный сигнал о высокой температуре.
Так что не стоит боятся дробить функциональны блоки на очень мелкие функции.
Функциональные блоки и принцип единственной ответственности.
И так... Принцип единственной ответственности. Для простоты многие объясняют этот принцип словами: "Функциональный блок должен отвечать за что-то одно", что очень похоже на принцип написания функции. Но мы же помним, что функциональный блок в контексте ОО является очень сложной единицей.
Так что вот финальная и относительно правильная формулировка принципа
Принцип единственной ответственности. Роберт Мартин "Чистая архитектура"Модуль должен отвечать за одного и только за одного актора.
Отвечаем на немой вопрос, а кто же такой актор. Актор - это объект или группа объектов, которые заинтересованы в одном и том же изменении.
И вот в том чтобы разобраться в этих акторах есть и основная проблема.
Что у нас часто бывает из такого... Ну первым, что попадается на глаза - это реализация логики блокировки внутри блока, которому эта блокировка предназначается. В итоге нам потребуется вносить изменения при изменении логики блокировки и при изменении логики работы объекта, которому предназначается этот блок.
Второй пример это обработка данных от визуализаций вместе с логикой объекта. Это все нужно выделять и разносить.
Ну и третий пример нарушающий этот принцип вы видели несколько строчек выше. Ну да. у меня там логика и за температуру и за поток.
Немного выводов.
Что в первую очередь стоит понимать? Принципы - это не закон. Их не всегда надо применять, а если вы решили следовать, то стоит хорошо обдумать применение.
Что касается принципа единственной ответственности, то вы вряд ли почувствуете толк на маленьких проектах, где у вас условные шесть клапанов, две бочки, два насоса.
Вы точно все похерите во время ПНР, даже не стоит винить себя за это.
Но вот если вы для своих задач пишите отдельную библиотеку, то вот там стоит немного заняться и посмотреть. а где же что можно положить под нож.
А у нас все по старому.
Если есть предложения/пожелания/вопросы: info@engcore.ru
