Обсуждение статьи "Библиотека для простого и быстрого создания программ для MetaTrader (Часть XXVII): Работа с торговыми запросами - выставление отложенных ордеров" - страница 4

Новый комментарий
 
Artyom Trishkin:

Зачем они отсылаются раз в секунду? Торговый сервер заспамить?

Это условный промежуток между повторами запроса. Можно настроить.
 
Artyom Trishkin:

А мне для реализации задуманного далее как раз нужны полноценные объекты. Но вы-то пока об этом не в курсе, и пытаетесь предлагать неэффективные для дальнейшей работы способы решения малой части поставленной задачи. А тут всё увязано воедино, и общая концепция одинакова - от этой малой части зависят остальные запланированные в дальнейшем вещи.

Впрочем, спасибо за ваше мнение - любое мнение полезно и имеет смысл.

ЗЫ. И, да - не страшно написать рабочую портянку кода, нежели постоянно переписывать под очередные задачи написанные бездумно неполноценные решения.

Ну, раз нужны, то нужны. Любопытно будет далее узнать для чего. 

ЗЫ. Не страшно, если бы это избавляло от изменений и переделок, но по факту не избавляет. Что Объект, что не Объект - все равно развитие концепции заставляет переделывать массу вещей. 

 
Реter Konow:

Ну, раз нужны, то нужны. Любопытно будет далее узнать для чего. 

ЗЫ. Не страшно, если бы это избавляло от изменений и переделок, но по факту не избавляет. Что Объект, что не Объект - все равно развитие концепции заставляет переделывать массу вещей. 

Вы не разделяете понятия "переделать" и "расширить". Переделать - это выкинуть в мусорку готовое и написать новое с нуля. А расширить - это добавить в готовое новый функционал.

По большей части здесь он как раз добавляется, а не переписывается от статьи к статье.
А вот при создании чего-то нового с нуля - да, много переписывается. Но это за кулисами статей. Единственные два исключения - это в самом начале были небольшие доработки уже опубликованного для расширения дальнейшей функциональности всех составляющих библиотеки, и вот сейчас - сначала обкатка решения на упрощённом коде, а затем - через одну статью - изготовление полноценных объектов-торговых запросов, и далее - изготовление класса работы с ними.
Сейчас пока всё сделано в одном месте - в торговом классе. Но там этого быть не должно - хоть это и торговля, но это не торговые методы - это способ управления торговыми методами.

 
Artyom Trishkin:

Вы не разделяете понятия "переделать" и "расширить". Переделать - это выкинуть в мусорку готовое и написать новое с нуля. А расширить - это добавить в готовое новый функционал.

По большей части здесь он как раз добавляется, а не переписывается от статьи к статье.
А вот при создании чего-то нового с нуля - да, много переписывается. Но это за кулисами статей. Единственные два исключения - это в самом начале были небольшие доработки уже опубликованного для расширения дальнейшей функциональности всех составляющих библиотеки, и вот сейчас - сначала обкатка решения на упрощённом коде, а затем - через одну статью - изготовление полноценных объектов- торговых запросов, и далее - изготовление класса работы с ними.
Сейчас пока всё сделано в одном месте - в торговом классе. Но там этого быть не должно - хоть это и торговля, но это не торговые методы - это способ управления торговыми методами.

Я все прекрасно разделяю и знаю о чем говорю. А вы не поняли смысла сказанного.

Ваша увлеченность превращением всего на свете в Объект, говорит о том, что вы не знаете его концептуальных границ. В ООП нет правила, требующего все подряд превращать в Объект, но вы похоже об этом не знаете.

Подумайте над тем, сколько времени вы будете заниматься Объектами, необходимость которых уже сейчас подрывается сжатым и готовым решением, на которое я указал. Что еще с этим можно придумать? У меня не хватает фантазии. Может у вас хватит. Дерзайте.  

 

К вопросу о том, что можно делать Объектом, а что нет.

1. Торговый запрос - это Объект.

2. Отложенный торговый запрос - нет. Почему? Потому, что если мы его сделаем Объектом, он будет точной копией Объекта "Торговый запрос" с одним отличием - критериями своего повтора и удаления. Это слишком малое отличие, чтобы отложенный торговый запрос "отпачковывать" от торгового запроса. 

 
Ну.., тоже мнение...
 
Понял в чем разница наших подходов. Почему простое решение вам не подходит.

Вы следуете принципу "все - Объект". Я следую принципу "все в Объект".

Вы создаёте много маленьких и простых Объектов, я один большой и очень сложный. Мои решения требуют сжимать содержание Объекта, чтобы развивать, а ваши - наполнять каждый Объект содержанием, чтобы он состоялся как оправданная сущность. 

Решение которое я привел не требует объектов отложенных запросов. Следующая ваша статья демонстрирует какое нагромождение сущностей и их взаимосвязей вы создали вокруг простой задачи - повтора сорвавшихся запросов к серверу. 

Всего то нужно, - повторить неудовлетворенный сервером запрос, но ваше решение, удивительным образом, порождает целый мир сущностей, в котором можно потеряться, как в джунглях. 

Я остаюсь удивлен такой практикой программирования и не знаю, как к этому относится. С одной стороны, это восхищает, с другой - возмущает. Если я буду так решать задачи, мне жизни не хватит сделать то, чего хочу. Поэтому, не могу дать однозначную оценку. 

Знаю одно: если бы вас прижали к стенке и потребовали решения завтра к вечеру, никаких объектов вы бы не создавали, а использовали мое решение, которое бы работало ничуть не хуже.


 
Реter Konow:
...Вы создаёте много маленьких и простых Объектов, я один большой и очень сложный...

Пётр, это что же, суперкласс? Получается впихнуть невпихуемое? :-) В книжках пишут, что это не есть гуд...

Замечу Артёму, что когда Анатолий писал серию статей о графике, то он приводил структуру взаимосвязей между классами (читай иерархию). К примеру. 

Артём, Вы проделали огромную работу. Учебник можно целый по ней составить. Местами даже подробнее Документации. И это круто. Но иногда не хватает иллюстраций в материале. Имхо конечно...

 
Denis Kirichenko:

Пётр, это что же, суперкласс? Получается впихнуть невпихуемое? :-) В книжках пишут, что это не есть гуд...

Замечу Артёму, что когда Анатолий писал серию статей о графике, то он приводил структуру взаимосвязей между классами (читай иерархию). К примеру. 

Артём, Вы проделали огромную работу. Учебник можно целый по ней составить. Местами даже подробнее Документации. И это круто. Но иногда не хватает иллюстраций в материале. Имхо конечно...

Спасибо.
Структура иерархии будет позже - к завершению. Не хочу её переделывать если вдруг понадобится поменять.
 
Denis Kirichenko:

Пётр, это что же, суперкласс? Получается впихнуть невпихуемое? :-) В книжках пишут, что это не есть гуд...

Все получается и работает хорошо. Каждому свое. 
Читаю статьи и никак не могу найти "генератор сущностей" - принцип по которому все это производится. Пытаюсь научится так мыслить и разобраться, почему у меня всё иначе. И в чем преимущество иного мышления (если оно есть). Артёму про схему библиотеки тоже говорил.


12345
Новый комментарий