Discussion of article "Library for easy and quick development of MetaTrader programs (part XXVII): Working with trading requests - placing pending orders" - page 4

New comment
 
Artyom Trishkin:

Why do they send them out once a second? To flood the trading server?

It's a conditional interval between request repetitions. It's configurable.
 
Artyom Trishkin:

And I need full-fledged objects to realise what I have planned further. But you are not aware of this yet, and you are trying to offer ineffective for further work ways of solving a small part of the task. But here everything is linked together, and the general concept is the same - the other things planned in the future depend on this small part.

Anyway, thanks for your opinion - any opinion is useful and makes sense.

ZЫ. And, yes - it's not terrible to write a working mess of code rather than to constantly rewrite incomplete solutions written thoughtlessly for the next tasks.

Well, if we need them, we need them. It will be interesting to find out why.

ZЫ. It wouldn't be terrible if it would get rid of changes and redesigns, but in fact it doesn't. What Object or not Object - all the same development of the concept forces to redesign a lot of things.

 
Реter Konow:

Well, if they're needed, they're needed. I'll be curious to see what for.

ZY. It wouldn't be terrible if it would save from changes and redesigns, but in fact it doesn't. What Object or not Object - all the same the development of the concept forces to redesign a lot of things.

You are not separating the concepts of "redesign" and "extend". To redesign is to throw a ready-made thing in the trash and write a new one from scratch. And to extend is to add new functionality to the ready-made.

For the most part, here it is just added, not rewritten from article to article.
But when creating something new from scratch, yes, there is a lot of rewriting. But that's behind the scenes in the articles. The only two exceptions - in the very beginning there were small modifications of the already published to expand further functionality of all library components, and now - at first - first testing the solution on simplified code, and then - through one article - making full-fledged objects-tradequeries, and then - making a class of work with them.
Now everything is done in one place - in the trade class. But it should not be there - although it is trade, but it is not trade methods - it is a way of managing trade methods.

 
Artyom Trishkin:

You are not separating the concepts of "redo" and "extend". To redesign is to throw away the ready-made one and write a new one from scratch. And to extend is to add new functionality to the ready-made one.

For the most part, here it is just added, not rewritten from article to article.
But when creating something new from scratch, yes, there is a lot of rewriting. But that's behind the scenes in the articles. The only two exceptions - in the very beginning there were small modifications of the already published to expand further functionality of all library components, and now - at first the solution is being tested on a simplified code, and then - through one article - making full-fledged objects - trade requests, and then - making a class of work with them.
Now everything is done in one place - in the trade class. But it should not be there - although it is trade, but it is not trade methods - it is a way of managing trade methods.

I share everything perfectly well and know what I'm talking about. And you are missing the point of what I am saying.

Your preoccupation with turning everything in the world into an Object shows that you don't know its conceptual boundaries. There is no rule in OOP that requires turning everything into an Object, but you don't seem to know about it.

Think about how much time you'll spend dealing with Objects, the need for which is already being undermined by the concise and ready-made solution I pointed out. What else can you come up with with this? I don't have enough imagination. Maybe you do. Go ahead.

 

To the question of what can be made an Object and what cannot.

1. a trade request is an Object.

2. A pending trade request is not. Why? Because if we make it an Object, it will be an exact copy of the Trade Request Object with one difference - its repeat and delete criteria. This is too small a difference to make a deferred trade request "packaged" from a trade request.

 
Well, also an opinion.
 
Understand the difference in our approaches. Why the simple solution doesn't work for you.

You follow the principle of "everything is an Object". I follow the "everything to Object" principle.

You create many small and simple Objects, I create one large and very complex one. My solutions require you to compress the content of the Object in order to develop, while yours require you to fill each Object with content in order for it to take place as a justified entity.

The solution I gave does not require deferred query objects. Your next article demonstrates what a clutter of entities and their interrelationships you have created around the simple task of replaying failed requests to the server.

All that is needed is to repeat the unsatisfied server request, but your solution surprisingly creates a whole world of entities in which one can get lost like in a jungle.

I'm left wondering about this programming practice and not sure how to feel about it. On the one hand, it is admirable, on the other hand, it is outrageous. If I solve problems in this way, I won't have enough time to do what I want. Therefore, I can't give an unequivocal assessment.

I know one thing: if you were pressed against the wall and demanded a solution by tomorrow evening, you would not create any objects, but use my solution, which would work no worse.


 
Реter Konow:
...You create many small and simple Objects, I one big and very complex....

Peter, is this a superclass? You can cram in what you can't cram in? :-) They write in books that it is not good.....

I would like to point out to Artyom that when Anatoly wrote a series of articles about graphics, he gave the structure of interrelations between classes (read hierarchy). For example.

Artyom, you have done a great job. You can write a whole textbook on it. In some places it is even more detailed than the Documentation. And that's cool. But sometimes there are not enough illustrations in the material. Imho, of course...

 
Denis Kirichenko:

Peter, what is this, super class? You can cram in what you can't cram in? :-) The books say that it is not good....

I would like to point out to Artyom that when Anatoly wrote a series of articles about graphics, he gave the structure of interrelations between classes (read hierarchy). For example.

Artyom, you have done a great job. You can write a whole textbook on it. In some places it is even more detailed than the Documentation. And that's cool. But sometimes there are not enough illustrations in the material. Imho, of course...

Thanks.
Hierarchy structure will be later - to finalise. I don't want to redo it if I suddenly need to change it.
 
Denis Kirichenko:

Peter, what is this, super class? Do you get to cram in what you can't cram in? :-) The books say that it is not good....

Everything turns out and works well. To each his own.
I'm reading articles and I can't find the "entity generator" - the principle by which all this is done. I'm trying to learn to think this way and to understand why I think differently. And what is the advantage of thinking differently (if any). I told Artyom about the library scheme too.


12345
New comment