Вопрос знатокам ООП. - страница 17
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я про количество классов. Каждый строк на 200.
А доступ насколько бы усложнился? У меня ведь глобальное ядро, которое отовсюду видно. В ООП мне бы пришлось от него отказаться. Как же тогда работать с элементами в окнах? У меня коматозное состояние начинается, когда пытаюсь представить.)))
Статический класс.
Vladimir Simakov:
А теперь к эффективности. Switch - это что в конечном итоге? Это последовательное сравнение параметра с константами. Внимание Петр, последовательное.
совсем необязательно.
это совсем не значит что Петер прав или свитч надо пихать везде, но тем не менее.
Да, именно так. Так что по скорости, очевидно, это самый быстрый в MQL вариант. А вот доступ к объектам класса в управляемой среде происходит опосредованно.
Вот-вот, про эту функцию поподробнее. У тебя она одна имеет чудовищных размеров switch, который выбирает одну из десятка нужных функций. В таком переключателе - очень легко ошибиться, случайно написав код, относящийся к одной из ветви не там.
С перегрузкой - все куда проще. У нас есть десять разных наследников, и каждый момент времени времени мы работаем с ОДНИМ классом, и в нем ОДНА перегружаемая функция. Мы не можем случайно написать ее в другом классе, поскольку для этого надо открывать совсем другой файл.
Плюс - само разбирательство в этом самом огромном switch'e - на мой взгляд, куда напряжнее, чем открытие одного нужного класса, и потом разбирательство только с одной функций.
На самом деле, в ассемблерном коде вся эта пергрузка в любом случае сводится к такому же swich'у, в зависимости от указателя this. Но в случае ООП - все это скрыто от программиста, и не мешает ему в работе. Без ООП - тебе придется с ним иметь дело.
Грубо говоря, когда ты идешь - ты ведь, в конечном итоге, посылаешь на свои мышцы в определенной последовательности сигналы, которые их двигают. Однако, на уровне сознания - ты просто помнишь, какое движение надо совершить. Вот, ООП - это именно такая "память, какое движение надо совершить". Ты же "не понимаешь, зачем помнить движение, если у нас есть куча мускулов, и нервов, подведенных к ним". Ну... я уже много раз говорил, для титанов запоминания, и правда, вполне достаточно помнить какие мышцы надо напрягать в какой последовательности, чтобы идти. Смысла помнить еще и это движение целиком - ну никакого. Для остальных же, кто не может так много помнить - куда разумнее помнить именно все движение целиком, а что там с мышцами, в какой последовательности они напрягаются и насколько - это разумнее скрыть от сознания.
Перегруженные функции для компилятора - просто разные функции, и никаких switchей.
А доступ насколько бы усложнился? У меня ведь глобальное ядро, которое отовсюду видно. В ООП мне бы пришлось от него отказаться. Как же тогда работать с элементами в окнах? У меня коматозное состояние начинается, когда пытаюсь представить.)))
С чего бы это ?
Глобальное ядро и ООП - это совершенно не исключающие друг друга вещи.
Как раз элементы в окнах должны быть инкапсулированны внутри классов окон, а не "Лежать на всеобщем обозрении". Как раз для того, чтобы никто не мог случайно "влезть не туда". Изменить одну переменную и ошибиться в ее расположении внутри гигантского глобального массива очень просто. Запросить же нужный интерфейс, и потом изменить эту же переменную в том объекте, который нужен, и при этом ошибиться - куда сложнее.
Перегруженные функции для компилятора - просто разные функции, и никаких switchей.
А как выбирается та, которая нужна ? Мы же говорим о виртуальных функциях и позднем связывании. Какая из перегружаемых функций будет вызвана ? Это определяется указателем this, который неявно передается при вызове. И как по-твоем происходит этот самый выбор ?
А как выбирается та, которая нужна ? Мы же говорим о виртуальных функциях и позднем связывании. Какая из перегружаемых функций будет вызвана ? Это определяется указателем this, который неявно передается при вызове. И как по-твоем происходит этот самый выбор ?
Вообще Пётр говорил не о виртуальных функциях.
Но в них тоже нет никаких switchей.
У класса, в котором есть виртуальные функции, есть таблица виртуальных функций.
И каждый объект этого класса содержит неявную переменную - указатель на таблицу виртуальных функций.
Если в потомке переопределяется одна или все виртуальные функции, то создаётся новая таблица, и экземпляры потомка содержат указатель на неё.
Вообще Пётр говорил не о виртуальных функциях.
Но в них тоже нет никаких switchей.
У класса, в котором есть виртуальные функции, есть таблица виртуальных функций.
И каждый объект этого класса содержит неявную переменную - указатель на таблицу виртуальных функций.
Если в потомке переопределяется одна или все виртуальные функции, то создаётся новая таблица, и экземпляры потомка содержат указатель на неё.
Вот-вот. Я и спрашиваю, как работает эта самая таблица ? В ассемблерном коде - это все тот же самый switch.
А насчет "говорил не о виртуальных функциях" - так ведь речь вроде как про "зачем ООП"... То есть, все-таки, именно о виртуальных функциях, а не о простых одинаковых названиях функций с разными аргументами.
Вот-вот. Я и спрашиваю, как работает эта самая таблица ? В ассемблерном коде - это все тот же самый switch.
Нет. Это просто массив указателей на функцию.
В ассемблерном коде у объекта берётся адрес таблицы.
В ней на определённой позиции берётся адрес функции.
И делается переход по этому адресу.
А насчет "говорил не о виртуальных функциях" - так ведь речь вроде как про "зачем ООП"... То есть, все-таки, именно о виртуальных функциях, а не о простых одинаковых названиях функций с разными аргументами.
Судя по его вопросу, он говорил о функциях с одинаковыми именами.
О виртуальных функциях он скорее всего даже не подозревает.