CArchive ar(&filein, CArchive::load); // на основе него обьект архив
ar >> m_sConfigName;
ar >> m_sConfigComment;
ar >> m_sAvtomatNumber;
ar >> m_sAvtomatType;
ar >> m_fMinDoze;
ar >> m_fAvansMin;
ar >> m_fAvansMax;
ar >> m_bAvansReturn;
ar >> m_fAvansTime;
ar >> m_sTovarName;
>> - перегруженный оператор с полиморфизмом... и пофиг чего в файл запихиваем, само разберется ))) это конечно строки из вижинл си, но ООП так ООП )))
Вопрос.
С какой целью это делать - независимость от типа архивируемых данных или независимость от типа и нахождения архива?
Если первое - то глупо и не эффективно.
Я бы не отказался от (что первое приходит на ум):Сообщение от capzap
- полноценных методов вместо действий с возможностью передачи аргументов в качестве локальных переменных метода да и просто поддержкой самих локальных переменных методов
- реализации полноценной инкапсуляции с private переменными и методами (не очень нравится, когда используешь ФБ (тот же класс в ООП) в программе, и в раскрытии списка высыпаются все его переменные и действия)
- правил хорошего тона использовать геттеры и сеттеры совместно с защищенными private переменными, минуя прямого доступа к свойству (переменной) объекта
- в моих проектах очень пригодилось бы наследование, тот же полиморфизм, интерфейсы или абстрактные классы
Примеры приводить не буду, не вижу смысла, кто понимает - тому очевидны преимущества.
rm -rf /bin/laden
когда управляешь несколькими объектами со схожими методами управления (или одним или несколькими интерфейсами), но отличающихся реализацией (алгоритмом)... полиморфизм совместно с наследованием облегчил бы задачу и понимание кода в разы....
Последний раз редактировалось dudanov; 25.01.2015 в 21:54.
rm -rf /bin/laden
я бы сказал понимание программы в целом...
rm -rf /bin/laden
всё это теория, на "пальцах" покажите где будете использовать, только не надо как выше предлагалось на Си,Яве и т.п. а конкретно применительно в пром.автоматике
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Перегрузка методов в данном случае необходима для прозрачности кода. В определении класса "Архиватор" должны быть объявлены все перегруженные методы (с одинаковым именем) для всех типов и комбинаций входных переменных, классов и т.п. А в используемом этот класс коде мы прозрачно архивируем любой тип данных, используя одно и то же имя метода, что очень и очень удобно.
Да, кстати, неэффективного тут ничего НЕТ, этот механизм позволяет программисту лишь использовать единое имя, а методы в откомпилированном коде разные и компилятор в процессе компиляции на основе используемых типов входных данных понимает какой метод на самом деле выполнять.
Последний раз редактировалось dudanov; 25.01.2015 в 22:14.
rm -rf /bin/laden
Да что тут придумывать?! Например, есть 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
Ваши права
Ответить с цитированием