Что может делать ООП-код, чего не может процедурный код?
ООП создано для того, чтобы работать и думать, как существа природы, давайте представим, если мы хотим разработать военную игру, где у нас есть транспортные средства с множеством типов, солдаты с множеством навыков и оружие с множеством спецификаций.
Разработка такой игры без ООП будет мучением для разработчика, чтобы отслеживать все эти виды объектов и управлять структурами данных и памятью хорошо, а также моделировать функции ООП как наследование будет трудно (хотя это может быть сделано), ООП сделал его легче думать и разрабатывать также легче писать читать и отлаживать код.
Иногда наличие ООП больше, чем необходимо, делает код недружелюбным для понимания и чтения (моя личная точка зрения), что мне не нравится.
На самом деле, я не думаю, что может существовать задача, которую нельзя рефакторить из процедурного кода в ООП или наоборот. Разница заключается в удобстве сопровождения и читабельности кода. Например, в процедурном коде вы можете ссылаться на глобальные и/или локальные данные (переменные). В дополнение к ним ООП добавляет еще одну область - внутренние переменные объекта (состояние). Использовать их в ООП очень просто и естественно, а процедурная реализация той же логики потребовала бы каких-то обходных путей с дополнительным кодом и структурами данных. Другими словами, ООП - это просто более короткие и приятные способы кодирования.
Как вы хотите построить обходной путь для перегруженных виртуальных функций, включая дерево наследования - что является самой важной частью ООП? Похоже, вы говорите о структурах, а не об ООП.
ООП создано для того, чтобы работать и думать как природные существа, давайте представим, если мы хотим разработать военную игру, где у нас есть транспортные средства с множеством типов, солдаты с множеством навыков и оружие с множеством спецификаций.
Разработка такой игры без ООП будет мучением для разработчика, чтобы отслеживать все эти виды объектов и управлять структурами данных и памятью хорошо, а также моделировать функции ООП как наследование будет трудно (хотя это может быть сделано), ООП сделал его легче думать и разрабатывать также легче писать читать и отлаживать код.
Иногда наличие ООП больше, чем необходимо, сделает понимание и чтение кода недружелюбным (моя личная точка зрения), что мне не нравится.
Форум о трейдинге, автоматических торговых системах и тестировании торговых стратегий
Что может делать ООП код, чего не может процедурный код?
Алена Верлейен, 2016.05.22 14:03
Я открываю эту тему в надежде собрать полезную информацию о преимуществах объектно-ориентированного программирования по сравнению с процедурным.
Кроме того, эта тема не зависит от языка, так как mql4 и mql5 предлагают один и тот же язык ООП (за исключением некоторых новых расширенных возможностей, пока недоступных в mql4).
Я не хочу "войны" между сторонниками и противниками ООП, поэтому эта тема будет тщательно модерироваться, не тратьте свое и мое время, пожалуйста.
Пожалуйста, приводите примеры и код, чтобы проиллюстрировать вашу точку зрения, а не высокую теорию или абстрактные концепции.
EDIT: хотя эта тема не зависит от языка, мы все еще говорим о торговле и mql4/mql5, поэтому никаких "военных игр" или примеров "яблок и апельсинов", пожалуйста.
Я большой поклонник ООП - не могу даже представить, что вернусь к процедурному MQL. На нем легче делать более сложные программы. В любом случае... беда с MQL в том, что новому пользователю трудно начать.
- Встроенные методы событий не являются OO. Вы должны подключиться к ним, что требует объявления прослушивающих объектов на корневом уровне. При такой конструкции нарушается один из основных принципов ООП.
- отсутствуют "системные" пакеты кода с общими паттернами. Это препятствует созданию совместимых пакетов между пользователями, а серьезному ООП-кодеру требуется много времени для создания своих частных пакетов. Неподдерживаемые префиксы имен классов (имен пакетов) являются лишь незначительной проблемой - когда вы все равно не можете повторно использовать внешний код.
Поэтому я бы не рекомендовал начинать изучать ООП прямо на MQL. Кодер должен знать, что ему нужно, чтобы заставить его работать.
Оператор "if...then...else..." должен сделать свою работу.
Да ладно ;) Не совсем так ;) Если что-то родное может сделать эту работу как-то странно, то это указатели, но в MQL есть ограничения. Если бы еще... код стал бы абсурдным. А если принять абсурдный код как ответ на вопрос этой темы, то он вообще устареет ;) Вы согласны с тем, что абсурд - это хороший рубеж? Давайте, скажите "да", только один раз и только ради моего эго ;)
Извините, но я не скажу "да"... код либо достигает своей цели, либо нет, если он работает в соответствии со спецификациями, то нет ничего абсурдного.
Вопрос в том, "что ООП может сделать такого, чего не может сделать процедурный"? Станислав говорил, что ООП может делать то же самое, что и процедурный, но "короче и красивее". Я склонен согласиться (за исключением идеи "короче", но это не так важно).
Программирование графических интерфейсов было тем, чем я занимался большую часть своего времени в качестве программиста. Невозможно написать полноценный графический интерфейс, который должен взаимодействовать в нескольких направлениях по принципу if then else. Вам потребуется столько утверждений, что код станет нечитабельным и, в конце концов, слишком медленным, что будет означать: Цель не достигнута, потому что я не хочу быть вынужденным пить чашку кофе после каждого клика, пока не увижу результат.
В силу того обстоятельства, что процессор ничего не знает об ООП, вы, конечно, можете кодировать все без него, просто используя указатели и сложные массивы. Но это абсурд. Я также могу нанять 10000 человек, которые будут рисовать содержимое моего экрана на пленке в режиме реального времени и последовательно транслировать его световым проектором на стену. Это тоже достижение цели?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Я открываю эту тему в надежде собрать полезную информацию о преимуществах объектно-ориентированного программирования по сравнению с процедурным программированием.
Кроме того, эта тема не зависит от языка, так как mql4 и mql5 предлагают один и тот же язык ООП (за исключением некоторых новых расширенных возможностей, пока недоступных в mql4).
Я не хочу "войны" между сторонниками и противниками ООП, поэтому эта тема будет тщательно модерироваться, не тратьте свое и мое время, пожалуйста.
Пожалуйста, приводите примеры и код, чтобы проиллюстрировать вашу точку зрения, а не высокую теорию или абстрактные концепции.
EDIT: хотя эта тема не зависит от языка, мы все еще говорим о торговле и mql4/mql5, поэтому никаких "военных игр" или примеров "яблок и апельсинов", пожалуйста.