когда управляешь несколькими объектами со схожими методами управления (или одним или несколькими интерфейсами), но отличающихся реализацией (алгоритмом)... полиморфизм совместно с наследованием облегчил бы задачу и понимание кода в разы....Сообщение от ASo
Последний раз редактировалось dudanov; 25.01.2015 в 21:54.
rm -rf /bin/laden
всё это теория, на "пальцах" покажите где будете использовать, только не надо как выше предлагалось на Си,Яве и т.п. а конкретно применительно в пром.автоматике
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Да что тут придумывать?! Например, есть 10 двигателей, управляемых частотными приводами разных производителей, подключенных к одному ПЛК по интерфейсу RS-485. Каждый частотник имеет свои команды, свою реализацию управления. Мне нужно ставить частотникам задачи: установить частоту в Х Гц, крути вперед, стоп, крути назад. Мне удобно будет создать единый интерфейс и реализовать его в каждом из классов: Schneder, ABB, Eaton и т.д. А дальше в программе тупо: Schneider.GoFWD или Eaton.STOP.
Или плохой пример?
И вообще, если бы приняли стандарты интерфейсов управления различными категориями устройств автоматики, это бы позволило, не только перейти на ООП в сфере автоматизации, но и производители предоставляли бы готовые классы, реализующих эти стандартизированные интерфейсы, что облегчило бы жизнь всем.
А оперирование, в том числе и считывание данных с этих устройств о состояниях, сводилось бы к простому созданию экземпляра класса с указанием параметров связи с устройством в конструкторе при его создании или методе в процессе выполнения программы. Ну а далее все просто, как три копейки, вызывая соответствующий метод, даешь команду, читаешь параметр или структуру параметров...
Последний раз редактировалось dudanov; 25.01.2015 в 22:53.
rm -rf /bin/laden
нормальный пример, как по учебнику. А в реальном производстве, тот кто заложил в проекте такое разнообразие двигателей с головой дружит? На каждый движок надо иметь отдельный ЗИП, на сервисное обслуживание надо оплачивать в каждый бренд. Я же писал, что программисту плк это ООП чисто для поднятия самооценки, в реальности особых преимуществ нет, под конкретный проект у меня будет свое ПОУ, например поменяв марку двигателя, я окно объявлений оставлю то же, а код поменяю под соответствующий алгоритм и главное загружу в контроллер только тот код, который необходим, а не все это наследование которое пойдет баластом в ООП
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
спорить не буду, у каждого свой подход... кто-то до сих пор знаю на счетах считает, и калькулятор на дух не переносит, есть и такие, они по своему правы... если ассемблерщику сказать про ООП, так он вообще отматюкает так, что мало не покажется... только вот кто быстрее возведет число 5 в 25 степень? тот кто со счетами? или кто быстрее программу напишет? тот кто пишет на ассемблере или на Java? думаю ответ очевиден...
ООП появилось из-за повышения сложности разрабатываемых приложений... так же как калькуляторы и ЭВМ появились по другой причине в свое время... поэтому если заниматься простыми проектами, то можно и без ООП и вообще на IL писать... это личное дело каждого, только вот я бы предпочел современный подход, не люблю я счеты, а ассемблером в свое время все же занимался, программы взламывал, кейгены писал... давно только вот это было... в прошлом веке...
Последний раз редактировалось dudanov; 25.01.2015 в 23:14.
rm -rf /bin/laden
Только хотел написать об безнадежном устаревании языков МЭК 61131-3, как зайдя по ссылке с удивлением обнаружил (надо почаще обращаться к стандартам), что в 3-й редакции исключен язык (сейчас любители дзен кода расстроятся) IL и введено понятие ООП, множество в связи с этим ключевых слов, типов данных и т.п.
Что я могу сказать?! Неплохо! Введено все то, что мне так не хватало! Еще бы хотябы Си-подобный язык ввели, а лучше Java. Обязательно прочту целиком стандарт. Подробнее здесь
to capzap: поспорь теперь с создателями стандарта, зря видимо они такую колоссальную работу проделали, ни к чему это все... уволить их там всех надо, бездельников... без обид...
Последний раз редактировалось dudanov; 25.01.2015 в 23:41.
rm -rf /bin/laden
о чем спорить то, я же говорю на локальных объектах можно и без ООП обойтись, а уровень предприятия всёравно делать будут на S-400 и мощнее, ни как не на ОВЕНе.Только хотел написать об безнадежном устаревании языков МЭК 61131-3, как зайдя по ссылке с удивлением обнаружил (надо почаще обращаться к стандартам), что в 3-й редакции исключен язык (сейчас любители дзен кода расстроятся) IL и введено понятие ООП, множество в связи с этим ключевых слов, типов данных и т.п.
Что я могу сказать?! Неплохо! Введено все то, что мне так не хватало! Еще бы хотябы Си-подобный язык ввели, а лучше Java. Обязательно прочту целиком стандарт. Подробнее здесь
to capzap: поспорь теперь с создателями стандарта, зря видимо они такую колоссальную работу проделали, ни к чему это все... уволить их там всех надо, бездельников... без обид...
ЗЫ и если мне так нравится ООП применять, я возьму мощный комп, поставлю его в серверный шкаф, на Яве напишу прогу, в которой могу сделать а-ля систему реального времени с циклом в районе единиц микросекунд, а не милли и будет он пахать на несколько объектов
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
процесс программирования (как и средства в нем использованные!) реальному производству по барабану - они нужны программисту, для создания шаблонов и возможности многократного использования кода, а соответственно, ускорение разработки, уменьшение стоимости, а также исключения повторения "граблей"... влезая в тему по управлению теми же двигателями - можно хорошо вычистить код, но уже через год будут сильные напряги вспоминать почему решено так а не иначе, и некоторые вроде как мелочи будут обязательно переделаны "как лучше" ))) а лучшее, против работающего и проверенного, как известно к добру не приводит!
в чем суть этого опуса, что в ООП, что без него, я буду менять только ту часть которая требуется из-за особенностей некоторой сущности (например двигатель)
При создании нового проекта, я смотрю по спецификации какой двигатель будет использоваться и вставляю в проект соответствующее ПОУ, которое создал для предшествующих проектов на конкретную модель движка, если такового не было, беру в качестве шаблона любой попавшийся, меняю то что нужно, а теперь что я делаю в ООП, создаю ПОУ добавляю ему extends и правлю ему те методы, которые отличаются, либо беру уже готовое решение. В чем измеряется разница скорости создания, в секундах?
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Ваши права
Ответить с цитированием