Настало время для разбора двух последних принципов дизайна, которые использует объектно-ориентированное программирование. принцип разделения интерфейсов, который нам позволяет иметь более гибкие классы и принцип инверсии зависимости, который позволяет избежать жесткого связывания компонентов. Они также работают и для ПЛК, в том числе в среде Codesys.
А теперь как в бразильских сериалах. В предыдущих сериях:
- Объектно-ориентированное программирование на ПЛК
- Классы и интерфейсы, методы и свойства
- Наследование, композиция, агрегация
- Принцип единственной ответственности
- Принцип открытости/закрытости
- Принцип подстановки Барбары Лисков
И за все это время был только синтетический код. Может стрим как-нибудь устроить с написанием всего интересного?
Принцип разделения интерфейсов
Так как интерфейсы декларируют определенное поведение объекта, то реализация интерфейсов с большим количеством методов может быть избыточным, так как в конечном итоге будет образовываться зависимость от методов, которые не используются.
Рассмотрим на примере клапанов…
Имеет интерфейс Valve, который содержит три метода — Открыть, Закрыть и Заблокировать. Этот интерфейс будут реализовывать два объекта. Первый — VLV1 — пользуется всеми методами, а вот VLV2WithoutBlock — реализует весь интерфейс, но метод Block не используется, но болтается балластом. Так что мы будем делить интерфейс.
Ну вот… Было слово, а стало шесть. наверно из-за таких трансформаций и не любят парадигму с объектиками. Однако, теперь объект, которые не использует блокировки о них ничего не знает, а VLV1 умеет в открытие закрытие, а также в блокировку.
В целом данный принцип был создан для того, чтобы лишний раз не прогружать измененные объекты. Ибо при изменении родительского класса, будут изменены дочерние, а это все прогружать, а если объекты наследуется, но изменения касаются методов, которые он не использует, то его все равно прогружать и вот такая цепочка зависимостей
Принцип инверсии зависимости
Принцип инверсии зависимости (Dependency Inversion Principle; DIP) утверждает, что наиболее гибкими получаются системы, в которых зависимости в исходном коде направлены на абстракции, а не на конкретные реализации.
Ну вот и все. Для более гибкой системы вам необходимо направлять зависимости на абстракции. пример с классами что выше.
Допустим у нас есть какой-то объект, который в своей логике имеет зависимость, но мы зависим от конкретного объекта VLV2WithoutBlock, то мы не можем использовать в работе другие объекты.
Но стоит указать в зависимостях интерфейс OpenCloser, то мы в объекте сможем использовать оба варианта клапанов, так как они оба реализуют данный интерфейс и имеют методы Open и Close c одинаковой сигнатурой.
Разумеется всегда будут исключения и например конкретные объекты в программе, а для Codesys это прям POU Program там будет зависимость прям от конкретных реализаций, чтоб это все запустить.
Итого
В конченом итоге есть краткие описание с небольшими примерами основных принципов дизайна классов, они же SOLID, есть описанные основы ООП, расписаны различные формы зависимостей и работа с ними.
Стоит понимать, что строго следовать всем принципам невозможно, а иногда и вредно. Разработка в соответствии со всеми принципами, да и в целом в объектно-ориентированной парадигме значительно дольше, чем простое процедурное программирование и дает профит на долгих дистанциях.
Некоторые подходы и приемы способны упростить жизнь прямо сейчас и если будет желание, то напишите об этом и мы разберем, что я сам употребляю в проектах.
Почта для связи: info@engcore.ru
ТГ канал здесь