ООП vs процедурное программирование
Не хочу создавать здесь холивар, но интересно, могут ли сторонники ООП предоставить сюда код решающий какую либо задачу, где наглядно видно, что это решение более эффективно, чем решение без ООП?
Я мастер решать задачи без ООП и хотелось бы сразиться с мастером решения задач с ООП.
Не хочу создавать здесь холивар, но интересно, могут ли сторонники ООП предоставить сюда код решающий какую либо задачу, где наглядно видно, что это решение более эффективно, чем решение без ООП?
Я мастер решать задачи без ООП и хотелось бы сразиться с мастером решения задач с ООП.
Это не та платформа, где можно воспроизвести сравнение - программа одностраничная(однофайловая). Здесь можно писать как угодно, и быстродействие и доступ к программе останется практически на одном уровне. Хотя наворотить лажи можно в любом стиле написания, хоть процедурном, хоть в ООП.
Это не та платформа, где можно воспроизвести сравнение - программа одностраничная(однофайловая). Здесь можно писать как угодно, и быстродействие и доступ к программе останется практически на одном уровне. Хотя наворотить лажи можно в любом стиле написания, хоть процедурном, хоть в ООП.
Не совсем понял Вас. Что значит "программа одностраничная"? Можно произвести простое сравнение решений одной задачи двумя разными подходами. При сравнении оценивать каждое решение по основным критериям: само решение, сжатость кода, читабельность кода.
Именно эти критерии и являются главными в программировании.
- www.metatrader5.com
Пишу огромные блоки кода занимающие сотни строк. Почти без комментариев. Без ООП. Код на русском. Все работает очень эффективно. Никаких проблем с орентированием в программе не испытываю, хотя имеется около 100 подключенных файлов. Наверное потому что уже привык и все давно запомнил. Поэтому главное - знать свою программу и хорошо ее понимать, остальное вторично. Имхо.
Насчет "эффективности" работы можно и поспорить.
Тоже самое касается модифицируемости - если ваш код будет использоваться на котировках другой точности - потребует ли он изменений, и легко ли будет их внести ?
Главная проблема в таких проектах - это как раз внесение изменений. Как показывает практика - чем больше блоки - тем больше вероятность внесения ошибок при модификации. Отсутствие комментариев - это не плюс, а минус. Именно поэтому, что надо многое запоминать.
Не хочу создавать здесь холивар, но интересно, могут ли сторонники ООП предоставить сюда код решающий какую либо задачу, где наглядно видно, что это решение более эффективно, чем решение без ООП?
Я мастер решать задачи без ООП и хотелось бы сразиться с мастером решения задач с ООП.
Я уже представил такой код выше. Имеется полностью виртуальный интерфейс, в рамках которого и идет работа с историей торговли. Такая же система у меня применена и в работе с текущей позицией, и в других подобных местах.
Именно за счет ООП осуществляется полное единство работы как в МТ4 так и в МТ5, причем в МТ5 - независимо от того, хеджевая или неттинговая система.
Кроме того, именно за счет ООП у меня в рамках одного эксперта можно легко использовать несколько ТС, различающихся по магикам.
В сущности - ООП придумано как раз для того, чтобы упростить поддержку кода. При этом приходится платить большими затратами во время написания. Если вы пишете код, используете его без модификаций, и потом удаляете - то, действительно, с ООП смысла возиться никакого нет. ООП дает преимущество именно тогда, когда один и тот же код требуется во многих местах, и периодически в него необходимо вносить изменения.
Соответственно, область применения и неприменения ООП определяется именно необходимостью поддержки и изменений кода.
Насчет "эффективности" работы можно и поспорить.
Тоже самое касается модифицируемости - если ваш код будет использоваться на котировках другой точности - потребует ли он изменений, и легко ли будет их внести ?
Главная проблема в таких проектах - это как раз внесение изменений. Как показывает практика - чем больше блоки - тем больше вероятность внесения ошибок при модификации. Отсутствие комментариев - это не плюс, а минус. Именно поэтому, что надо многое запоминать.
Универсальность блоков - еще один критерий оценки. Безусловно, блок должен быть используемым для широкого спектра задач и легко приспосабливаться к изменениям условий. У меня именно так. Например, я использую так называемую технологию "фокуса". То есть значения основных параметров все время фиксируются в глобальных переменных, а эти переменные и проставлены во всех блоках.
Универсальность блоков - еще один критерий оценки. Безусловно, блок должен быть используемым для широкого спектра задач и легко приспосабливаться к изменениям условий. У меня именно так. Например, я использую так называемую технологию "фокуса". То есть значения основных параметров все время фиксируются в глобальных переменных, а эти переменные и проставлены во всех блоках.
Боюсь, глобальные переменные - это также минус. Глобальных пременных, доступных во всех блоках - должно быть как можно меньше. Как раз для того, чтобы каждый блок получал исключительно только те данные, которые ему необходимы, причем, везде, где можно - только в константном виде, чтобы не было возможности изменить то, что изменения не предполагало.
В моих проектах глобальнные переменные только две - это объект класса CExpert, функции которого инкапсулируют функциональность Init(), OnTick() и прочих событий, и объект CLogFile - лог-файл, в который выводится трассировка, поскольку трассировочные макросы должны работать из любого места программы.
Надеяться на память - не лучшее решение, на мой взгляд, как минимум, потому, что как говорил Шерлок Холмс - в один прекрасный момент нужные знания окажутся похороненными под горой ненужного хлама. Ну и подвести память тоже вполне себе может.
Боюсь, глобальные переменные - это также минус. Глобальных пременных, доступных во всех блоках - должно быть как можно меньше. Как раз для того, чтобы каждый блок получал исключительно только те данные, которые ему необходимы, причем, везде, где можно - только в константном виде, чтобы не было возможности изменить то, что изменения не предполагало.
В моих проектах глобальнные переменные только две - это объект класса CExpert, функции которого инкапсулируют функциональность Init(), OnTick() и прочих событий, и объект CLogFile - лог-файл, в который выводится трассировка, поскольку трассировочные макросы должны работать из любого места программы.
Надеяться на память - не лучшее решение, на мой взгляд, как минимум, потому, что как говорил Шерлок Холмс - в один прекрасный момент нужные знания окажутся похороненными под горой ненужного хлама. Ну и подвести память тоже вполне себе может.
Нужно на практике сравнить. Иначе это бесполезное обсуждение.
Почему же "бесполезное" ? Очень даже полезное.
Только как сравнить на практике "легкость поддержки" ?
Вот, скажем, код написанный одним огромным блоком, и код, разбитый на функциональные части - внесение изменений в обоих случаях совершенно одинаковое. Разница лишь в том, что в первом случае - надо помнить про все связи, на которые повлияет модификация, и учесть их. А во-втором случае - поскольку блоку доступны только те связи, которые ему нужны для работы - модификация затронет все доступные связи. Ничего помнить не надо - последовательно корректируем все, что доступно изменяемому блоку.
Вот как тут оценить разницу ? Работы-то совершенно одинаковое количество !
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования