ООП для школьников. - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ОК. Дайте свое определение геттера.
это не лошадь
это не лошадь
Я думал, что имею дело с человеком, который способен объяснить то, что знает. А тут даже на уровне определений беда.
Я думал, что имею дело с человеком, который способен объяснить то, что знает. А тут даже на уровне определений беда.
Да фантазируйте как угодно, мне тут с вами с некоторыми тоже все давно понятно ,готовы и уши отморозить назло бабушке.
Да фантазируйте как угодно, мне тут с вами с некоторыми тоже все давно понятно.
Все то Вам понятно. Только объяснить не можете ))
Все то Вам понятно. Только объяснить не можете ))
Продолжайте отмораживать уши назло бабушке.
С первой минуты её создания читаю.
читать не достаточно, имхо, нужно пробовать ставить задачи и писать в процедурном стиле, затем (это не сложно) эту задачу переписывать в стиле ООП
как неоднократно уже писал ТС, ООП позволяет быстро масштабировать задачу, ускоряет разработку и уменьшает кол-во ошибок при написании программы
применительно к MQL: одна из нелюбимых задач мною - частичное закрытие серии ордеров, при процедурном стиле программировании после вызова подпрограммы которая осуществит закрытие одного ордера, нужно будет организовать обработку ошибок - что делать если не получилось все ордера частично закрыть на одном вызове? - не дал сервер частично закрыть? - спрашивал в начале года, ну как обычно кто на что гаразд, в 99% случаев все распространенные решения свелись к анализу комментария ордера - типа там читай, сервер там все напишет.....имхо, не профессионально
В стиле ООП эта задача решается "в 2 клика", вызываем метод которые частично закрывает ордер, а сами данные о состоянии ордера - тикет, необходимость его модификации..... и методы которые работают с ордером храним в классе ОРДЕР - решение максимально гибкое и масштабируемое для последующих задач, имхо
так же и задачи с графикой в MQL - имеете одну текстовую метку не проблема с ней работать, а если имеете 10-100 меток? - а если нужно цветовую схему поменять, выборочно для одних меток "коралловый" цвет, а для других "перламутровый с пуговицами"?.... а через неделю потребовалось добавить еще 3 кнопки.... а через неделю еще потребовалось убрать 10 кнопок....
ЗЫ: топик по очередной борьбе с ветряными мельницами .... нет, вспомнил кого то (фамилию забыл ))) ) - кто сказал, что земля круглая, а потом его сожгли? )))) - вот так и выглядит борьба с безграмотностью и/или с расширением кругозора
читать не достаточно, имхо, нужно пробовать ставить задачи и писать в процедурном стиле, затем (это не сложно) эту задачу переписывать в стиле ООП
как неоднократно уже писал ТС, ООП позволяет быстро масштабировать задачу, ускоряет разработку и уменьшает кол-во ошибок при написании программы
применительно к MQL: одна из нелюбимых задач мною - частичное закрытие серии ордеров, при процедурном стиле программировании после вызова подпрограммы которая осуществит закрытие одного ордера, нужно будет организовать обработку ошибок - что делать если не получилось все ордера частично закрыть на одном вызове? - не дал сервер частично закрыть? - спрашивал в начале года, ну как обычно кто на что гаразд, в 99% случаев все распространенные решения свелись к анализу комментария ордера - типа там читай, сервер там все напишет.....имхо, не профессионально
В стиле ООП эта задача решается "в 2 клика", вызываем метод которые частично закрывает ордер, а сами данные о состоянии ордера - тикет, необходимость его модификации..... и методы которые работают с ордером храним в классе ОРДЕР - решение максимально гибкое и масштабируемое для последующих задач, имхо
так же и задачи с графикой в MQL - имеете одну текстовую метку не проблема с ней работать, а если имеете 10-100 меток? - а если нужно цветовую схему поменять, выборочно для одних меток "коралловый" цвет, а для других "перламутровый с пуговицами"?.... а через неделю потребовалось добавить еще 3 кнопки.... а через неделю еще потребовалось убрать 10 кнопок....
ЗЫ: топик по очередной борьбе с ветряными мельницами .... нет, вспомнил кого то (фамилию забыл ))) ) - кто сказал, что земля круглая, а потом его сожгли? )))) - вот так и выглядит борьба с безграмотностью и/или с расширением кругозора
На мой взгляд, в mql очень узок набор задач которые надо решать посредством ООП. Сам язык, мне кажется, ничто иное как ООП на С++ или ещё чего-то. И в это ООП предлагается ООП в виде стандартной библиотеки. А к этому ООП от ООП предлагается впендюрить, иначе не скажешь, ещё ООП. А потом ещё одну ступень... Правильно сказал Колдун, хоть и злой, но доброжелательный, для моих задач ООП как собаке поворотка. И какой прок от постановки задачи и последующей реализации её посредством ООП если эту задачу без проблем можно решить в процедурном стиле.
Вот к примеру взять .mqh от fxsaber`a для написания кодов для МТ5 так-же как для МТ4. Может кому-то это и надо, но посмотрите кому... Тому кто не хочет или абсолютно не может освоить mql5. Или взять iCanvas у Николая ..., забыл фамилию, ну вы поняли. Вроде-бы полезная библиотека, но в ней разобраться не просто, а никакой документации, хотя-бы маломальского описания нет. Это не претензия, извини Николай, это факт. Так-что когда я решил попробовать написание графической метки, мне оказалось проще написать не обращаясь ни к стандартной библиотеке, ни к библиотеке Николая.
На мой взгляд, в mql очень узок набор задач которые надо решать посредством ООП. Сам язык, мне кажется, ничто иное как ООП на С++ или ещё чего-то. И в это ООП предлагается ООП в виде стандартной библиотеки. А к этому ООП от ООП предлагается впендюрить, иначе не скажешь, ещё ООП. А потом ещё одну ступень... Правильно сказал Колдун, хоть и злой, но доброжелательный, для моих задач ООП как собаке поворотка. И какой прок от постановки задачи и последующей реализации её посредством ООП если эту задачу без проблем можно решить в процедурном стиле.
к сожалению Вы правы процентов на 90%, но лишь потому, что торговые стратегии которые просят написать трейдеры .... скажу прямо, примитивные, было некоторое оживление при появлении возможности в MQL создавать качественные графические панели, но оказалось, что и это не нужно конечному пользователю - тут в общем проблема индустрии, публика хоть и разношерстная, но .... нужна лишь одна кнопка - бабло ...
Вот к примеру взять .mqh от fxsaber`a для написания кодов для МТ5 так-же как для МТ4. Может кому-то это и надо, но посмотрите кому... Тому кто не хочет или абсолютно не может освоить mql5.
я пользуюсь этой библиотекой, т.к. мне нужен МТ5, но совершенно не хочется тратить время на изучение ордерной системы, правда пробовал пару раз спросить, что да как в ветке новичков МТ5... результат отрицательный - на этом форуме, по сути, нет носителей знания как работает ордерная система МТ5, ответы на мои вопросы... ну в общем "ералаш отдыхает", если помягче
Или взять iCanvas у Николая ..., забыл фамилию, ну вы поняли. Вроде-бы полезная библиотека, но в ней разобраться не просто, а никакой документации, хотя-бы маломальского описания нет. Это не претензия, извини Николай, это факт. Так-что когда я решил попробовать написание графической метки, мне оказалось проще написать не обращаясь ни к стандартной библиотеке, ни к библиотеке Николая.
пользовался пару раз библиотекой от @Nikolai Semko - ничего не обычного, подключил и пользуйся... принцип как у примерно как 99% ежедневно выходящих советников в КБ - там же модератор не заморачивается с ордерной системой? - подключил СБ написанной в виде ООП и штампует советников каких придумает
На мой взгляд, в mql очень узок набор задач которые надо решать посредством ООП. Сам язык, мне кажется, ничто иное как ООП на С++ или ещё чего-то. И в это ООП предлагается ООП в виде стандартной библиотеки. А к этому ООП от ООП предлагается впендюрить, иначе не скажешь, ещё ООП. А потом ещё одну ступень... Правильно сказал Колдун, хоть и злой, но доброжелательный, для моих задач ООП как собаке поворотка. И какой прок от постановки задачи и последующей реализации её посредством ООП если эту задачу без проблем можно решить в процедурном стиле.
Вот к примеру взять .mqh от fxsaber`a для написания кодов для МТ5 так-же как для МТ4. Может кому-то это и надо, но посмотрите кому... Тому кто не хочет или абсолютно не может освоить mql5. Или взять iCanvas у Николая ..., забыл фамилию, ну вы поняли. Вроде-бы полезная библиотека, но в ней разобраться не просто, а никакой документации, хотя-бы маломальского описания нет. Это не претензия, извини Николай, это факт. Так-что когда я решил попробовать написание графической метки, мне оказалось проще написать не обращаясь ни к стандартной библиотеке, ни к библиотеке Николая.
Применение ООП предполагает уровень сложности задач, намного более высокий, чем в алготрейдинге. Поэтому идут споры. ООП нужен профессиональным программистам и разработчикам для работы со сложными программами. Здесь мало места для столь серьезного подхода. Объяснять смысл ООП на маленьких примерах неправильно. Смысл ООП в масштабной работе с огромным объемом данных и функций. Разнообразие данных требует разделения и классификации, и тогда возникает актуальность инкапсуляции описания, наследования свойств и методов между разделенными иерархией классами.
На маленьких задачах этого смысла не объяснить.