Вопрос знатокам ООП. - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если программист входит в мир форекса, то тут не надо быть профессионалом и знать ООП.
Лучше изучить тонкости рынка и заниматься разработкой прибыльной торговой стратегии. И не важно применяешь ООП или нет. От этого прибыльность советника не пострадает.
Не надо тратить свою энергию впустую.
Джорж, тут дело не только в памяти. Я создал себе удобную среду разработки, используя родной язык и еще английский. Двуязычный код запоминается НАМНОГО лучше моноязычного. Особенно, когда не зациклен на стандартных словах и называешь переменные как хочешь. Проверено. Просто наплевал на профессионализм в программировании и стал писать как удобно. В результате стал быстро ориентироваться в своем коде и легко его читать, вспоминать и развивать. Дальше ты знаешь...
Не думаю, что это может помочь. Для меня название переменных на любом языке выветривается из памяти практически моментально, встал из-за компьютера, и уже помню лишь общие принципы, и не могу сказать, какие переменные вводились в том или ином месте.
Кстати, именно поэтому я всегда использую пары файлов mqh-mq5, а не пишу классы полностью в файлах mqh - мне надо часто заглядывать в заголовочные файлы, как раз для того, чтобы напомнить себе, что доступно в том или ином случае, у меня открыты на вкладках нужные заголовочные mqh, и я переключаюсь на них, когда надо еще раз освежить эту информацию. Когда весь класс (тем более несколько) описаны в одном файле mqh - "прыгание" по этому файлу, даже с помощью закладок напряжнее.
Держать всю структуру в своей памяти я не могу, хотя, в молодости, как уже говорил, писал даже на ассемблере, а там других вариантов нет - у тебя есть только адреса памяти, и максимум, что позволяет макроассемблер - это создавать названия тех или иных областей с помощью макроподстановок. Так тоже можно. Но, я уже давно убедился в том, что количество ошибок при этом куда больше, а отлаживать такой код куда сложнее.
Пример уже был дан выше - возникла ошибка, по какой-то причине переменная неверно модифицируется. А к переменной имеется доступ из кучи мест программы. Как выловить место, где ошибка ? С инкапсуляцией ООП все очень просто - ставим точку останова в интерфейсной функции, которая модифицирует переменную, и как только неверная модификация происходит - мы останавливаемся, и сразу, по иерархии вызовов, видим, откуда была произведена некорректная модификация. А с твоим, Петер, подходом, мы должны перелопачивать весь код, просматривая все места, где происходит обращение к этой переменной, ставя везде точки останова, и анализируя все обращения, а не только неверное.
В том то и дело, что может пострадать. Знакомый по причине наличия ошибки в коде потерял часть депозита, а ООП как раз и у меньшает вероятность ошибок.
Это значит что он не хороший программист. В сложных конструкциях ООП можно больше запутаться чем без него.
Классы надо применить там, где это необходимо. Вот я заметил, что у некоторых программистов есть как-то мания, всюду применяют много функций, там где нет необходимости. Так происходит и с классами.
Вместо того чтобы написать компактную и короткую программу без ООП, некоторые программисты начинают применить классы, много функций, и простое решение превращается в километровый текст.
Это значит что он не хороший программист. В сложных конструкциях ООП можно больше запутаться чем без него.
При прочих равных ? Очень сомневаюсь. Если сложность конструкций одинакова - то с ООП разобраться получается куда проще.
Однако, это не отменяет правила "из пушки по воробьям", не имеет смысл использовать большие ООП-навороты там, где задача очень проста и компактна.
Хотя, как тут выше уже говорили - ООП позволяет набирать библиотеки классов, которые потом используются во многих проектах.
Скажем, те же классы массивов, классы файлов... Даже когда пишешь очень простой индикатор, не используя ООП, куда проще при необходимости объявить класс CFile, и использовать его функции, чем брать стандартные функции работы с файлами. Я уж не говорю за возможность легко заменить CFile на более специфичные, скажем, у меня есть класс CLogFile - с возможностью автоматической вставки времени и некоторых дополнительных данных в строки (для лог-файлов) или класс CIniFile, который умеет организовывать данные в стандартные ini-файлы, и затем их при необходимости считывать и использовать.
Это значит что он не хороший программист. В сложных конструкциях ООП можно больше запутаться чем без него.
Классы надо применить там, где это необходимо. Вот я заметил, что у некоторых программистов есть как-то мания, всюду применяют много функций, там где нет необходимости. Так происходит и с классами.
Вместо того чтобы написать компактную и короткую программу без ООП, некоторые программисты начинают применить классы, много функций, и простое решение превращается в километровый текст.
А ничего, что фактическая работа - это сотня строк, а остальные пара тысяч - это давным давно написанная и отлаженная библиотека? )))
Если программист в своей программе использует готовые классы, как например эти: CTrade, CAccountInfo, CPositionInfo, то это еще не значит что его программа основана на ООП.
Это зависит от того, программист сам создает подобные классы, или просто применяет их не зная внутренность (на уровне исходного текста) этих классов.
....
Пример уже был дан выше - возникла ошибка, по какой-то причине переменная неверно модифицируется. А к переменной имеется доступ из кучи мест программы. Как выловить место, где ошибка ? С инкапсуляцией ООП все очень просто - ставим точку останова в интерфейсной функции, которая модифицирует переменную, и как только неверная модификация происходит - мы останавливаемся, и сразу, по иерархии вызовов, видим, откуда была произведена некорректная модификация. А с твоим, Петер, подходом, мы должны перелопачивать весь код, просматривая все места, где происходит обращение к этой переменной, ставя везде точки останова, и анализируя все обращения, а не только неверное.
Да, у меня ядро модифицируется во всех частях программы и ошибки случаются, но обхожусь без точек останова. Вычисляю в уме и ставлю в нескольких местах алерт, для проверки значений. Так и нахожу. Подчеркну, - я очень хорошо знаю свою программу.
Но, плюс в том, что при таком знании, отсутствии синтаксических препятствий и родном языке, я имею огромные возможности быстрого развития. И именно поэтому, я против ООП в своих решениях.
Разделение кода, его чужеродная моно-язычность, новый синтаксис, доп.правила - все это затормозит в развитии программу. Я потеряю больше сил и получу меньший результат. Я это точно знаю.
Если бы в моих задачах было сборка и отладка программы из готовых кусков кода, - тогда только ООП и библиотеки. Прикрутка и разработка новых решений - разные вещи. Многие ратуют за ООП, потому что хотят использовать куски чужого кода и сэкономить силы. Я создаю свои решения по авторской технологии и у меня иные потребности и взгляды на ООП.
Да, у меня ядро модифицируется во всех частях программы и ошибки случаются, но обхожусь без точек останова. Вычисляю в уме и ставлю в нескольких местах алерт, для проверки значений. Так и нахожу. Подчеркну, - я очень хорошо знаю свою программу.
Но, плюс в том, что при таком знании, отсутствии синтаксических препятствий и родном языке, я имею огромные возможности быстрого развития. И именно поэтому, я против ООП в своих решениях.
Разделение кода, его чужеродная моно-язычность, новый синтаксис, доп.правила - все это затормозит в развитии программу. Я потеряю больше сил и получу меньший результат. Я это точно знаю.
Если бы в моих задачах было сборка и отладка программы из готовых кусков кода, - тогда только ООП и библиотеки. Прикрутка и разработка новых решений - разные вещи. Многие ратуют за ООП, потому что хотят использовать куски чужого кода и сэкономить силы. Я создаю свои решения по авторской технологии и у меня иные потребности и взгляды на ООП.
Я советую хоть раз использовать шаблон диалогового окна в VC++, создавая приложение на основе CDialog из MFC, установить на него всякие Controls в визуальном режиме, использовать готовые функции, чтобы понять всю мощь ООП.
И еще добавлю что в Borland C++, созданы очень удобные классы для работы с Oracle. Я с ним работал до 2012 года, сейчас не знаю как.
Я советую хоть раз использовать шаблон диалогового окна в VC++, создавая приложение на основе CDialog из MFC, установить на него всякие Controls в визуальном режиме, использовать готовые функции, чтобы понять всю мощь ООП.
И еще добавлю что в Borland C++, созданы очень удобные классы для работы с Oracle. Я с ним работал до 2012 года, сейчас не знаю как.
на дворе вторая половина 2019....но и 20-м и в 25-м и в .... также будут рассуждать о необходимости использования ООП ?
))))
нравится пользуемся, не нравится - ну не стой ноги сегодня встал, не пользуемся
привык писать программы путем использования написанных ранее небольших подпрограмм - пиши, не с той ноги встал... ну подставь все эти подпрограммы в исходный код и получи одну большую портянку кода
дали людям большие возможности ЯП, все равно не так, обрежь функционал до чистого С, опять не так будет ))))
ЗЫ: подозреваю что все равно кто то из разработчиков почитывает форум... думаю что эта ветка настроение им точно поднимает! ))))