ООП vs процедурное программирование - страница 35
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Будьте внимательней, не идет речь о внутренних переменных МТ, а о внутренних переменных объекта, которые вы изолировали, предотвратив возможность считывания их значений во время отладки и написания кода...
Дык я и говорю - когда вы отлаживаете эксперт - разве вам не нужны внутренние переменные МТ ?
Точно так же, в данном случае, с объектом торгового процессора - если вы отлаживаете, скажем, методику выставления отложек в вашей ТС - зачем вам иметь доступ ко внутренним переменным торгового процессора ?
Андрей еще более клиничный чем Петер или Сансаныч, зря время тратите
Молодежь надо учить.
Кроме того, возможно, в словах оппонентов есть и рациональное зерно. Мне бы, скажем, такую память, как у Петера - я бы, мож, тоже с ООП не заморачивался.
Точно так же и в других местах - если какие-то данные требуются - значит, этот блок должен предоставить соответствующий интерфейс.
Так и я об том же... Вместо того чтобы просто увидеть значение необходимой переменной, нужно думать как к ней прицепить подходящий интерфейс, а потом его обратно отцепить. :)
Выглядит это как занятие для мазохистов в программировании :)
Да уж.. хрен редьки не слаще :) Идея в адекватном языке программирования, чтобы облегчить отладку и написание кода с минимумом телодвижений, а тут имеем полностью противоположную ситуацию...
Это не "противоположная ситуация". Действительно, ООП требует некоторых дополнительных действий. Однако, это с лихвой компенсируется удобством поддержки и модификации системы.
Вот, опять же - возвращаясь к торговому процессору - он написан, и используется в куче ТС. Именно изоляция его внутренностей от ТС, и работа только через виртуальный интерфейс - позволяет не думать о том, какие там в нем переменные, и чему они равны. Если выявляются ошибки - они будут внутри процессора, и их исправлять надо будет внутри реального класса, не затрагивая классы ТС. Если ошибка будет в самой ТС - то она не будет затрагивать переменные торгового процессора.
Реально инкапсуляция - это очень полезная методика.
Да уж.. хрен редьки не слаще :) Идея в адекватном языке программирования, чтобы облегчить отладку и написание кода с минимумом телодвижений, а тут имеем полностью противоположную ситуацию...
Облегчение отладки как раз и достигается за счет разграничения ответственности в каждом классе: каждый класс отвечает за свой набор переменных. Ни один другой класс не имеет права изменять их значения. В итоге большинство проблем отсекается уже на этапе компиляции программы. А доступ к переменным из любого места в программе можно сравнить с десятком штурвалов на одном корабле.
Молодежь надо учить.
Кроме того, возможно, в словах оппонентов есть и рациональное зерно. Мне бы, скажем, такую память, как у Петера - я бы, мож, тоже с ООП не заморачивался.
1. На сколько прибыльность Ваших советников возросла от применения ООП?
2. На сколько уменьшилась наработка на отказ Ваших советников от применения ООП?
Так и я об том же... Вместо того чтобы просто увидеть значение необходимой переменной, нужно думать как к ней прицепить подходящий интерфейс, а потом его обратно отцепить. :)
Выглядит это как занятие для мазохистов в программировании :)
Вон, выше по теме Петер выкладывал вам одну, не самую большую свою структуру.
Вы в ней с легкостью разберетесь ?
Этот самый "мазохизм" - как раз позволяет во-первых, не залезть в рабочий код, и не испортить его. А во-вторых - сразу проектировать структуру системы так, чтобы предоставлять нужные данные в соответствующие блоки программы.
Да, действительно, бывает такие ситуации, когда ВНЕЗАПНО выясняется, что получить необходимые данные - практически невозможно. Они скрыты за несколькими виртуальными интерфейсами. Однако, такая ситуация ясно показывает, что система изначально была неправильно спроектирована, в ней не предусматривалась передача этих данных. Такая ситуация - действительно, очень неприятна. Приходится либо на скорую руку лепить "костыли" в виде дополнительных интерфейсов, либо вобще реструктурировать всю систему. Ну... это мотивирует программиста к более тщательному продумыванию архитектуры системы.
По меньше бы эмоций и рефлексии и побольше бы конкретики по сути обсуждения - вам бы цены бы не было. :)
здесь уже нет сути в этом обсуждении. Вы принципиально флудите и делаете вид что тупите.
Если модератор потрёт последние пару страниц как не относящиеся к теме ветки и программированию вообще - будет редкий случай когда я поддержу его действия.
1. На сколько прибыльность Ваших советников возросла от применения ООП?
2. На сколько уменьшилась наработка на отказ Ваших советников от применения ООП?
1. Ни насколько. Прибыльность не зависит от ООП.
2. На мой взгляд, на порядок (в десять раз). Но главный выигрыш от ООП - в поддержке кода. Сейчас я очень быстро разбираюсь в коде, который писал год и более назад. Хорошо помню, как я разбирался в своих ранних программах на ANSI С - в чисто процедурном стиле. Это было куда труднее.
Облегчение отладки как раз и достигается за счет разграничения ответственности в каждом классе: каждый класс отвечает за свой набор переменных. Ни один другой класс не имеет права изменять их значения. В итоге большинство проблем отсекается уже на этапе компиляции программы. А доступ к переменным из любого места в программе можно сравнить с десятком штурвалов на одном корабле.
Никак не могу понять, почему я в своей работе НИКОГДА ничего подобного не встречал. Откуда проблемы разграничения доступа к переменным у ОДНОГО разработчика в одной не очень большой программе? Было бы 100 разработчиков, каждый из которых писал бы по 100 функций. Теоретически можно было бы придумать. Но практически программирование почти 40 лет развивалось до ООП, написано горы кода и ни разу ничего подобного не слышал.