Discussing the article: "Developing a Replay System (Part 32): Order System (I)"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Developing a Replay System (Part 32): Order System (I).
Of all the things that we have developed so far, this system, as you will probably notice and eventually agree, is the most complex. Now we need to do something very simple: make our system simulate the operation of a trading server. This need to accurately implement the way the trading server operates seems like a no-brainer. At least in words. But we need to do this so that the everything is seamless and transparent for the user of the replay/simulation system.
To say that the EA must be the same means not to compile it for use in a tester and then compile it again for use in the real market. This would be much simpler and easier from a programming point of view, but would create problems for the user, requiring the constant recompilation of the EA. So, to ensure the best user experience, we need to create an EA that will require only one compilation. Once this is done, it can be used both in the real market and in the tester.
The critical part of using the EA in the real market, even on a demo account, is the easiest to implement. So, we start there. Please note that we will start with a very basic model. We will gradually increase the complexity of the EA and enhance its capabilities to eventually create the EA that can be used both for replay/simulation and on a demo or live account. The first thing we will do is borrow most of the code previously explained in other articles published here in the community. These articles belong to me, so I see no problem in using this information. We will make some changes to make the system flexible, modular, reliable and robust. Otherwise, we may at some point find ourselves in a dead end, which will make further development of the system in all respects impossible.
This is just the beginning, as the task is very complex. First of all, we need to know how the class inheritance system is currently implemented in the EA. We have previously seen this in other articles within this series. The current inheritance diagram is shown in Figure 01:
Figure 01: Current EA class inheritance diagram
Although this diagram works very well for what has been done so far, it is still far from what we really need. This is not due to the fact that it is difficult to add the C_Orders class to this inheritance scheme. Actually, this can be achieved by deriving the C_Orders class from the C_Study class. But I don't want to do this. The reason lies in a very practical issue that is sometimes ignored by most programmers working with OOP (Object Oriented Programming). This issue is known as encapsulation. That is, know only what you need to do your job. When we create a hierarchy of classes, we shouldn't let some classes know more than they really need to know. We should always favor the kind of programming where each class knows only what it really needs to know to perform its task. Therefore, maintaining encapsulation while adding the C_Orders class to the diagram shown in Figure 01 is practically impossible. Therefore, the best solution to this problem is to remove the C_Terminal class from the inheritance block as shown in Figure 01 and pass it into the same block as an argument or parameter, which can be used in a much more appropriate way. So the control over who receives what information will be exercised by the EA code, and this will assist in maintaining information encapsulation.
Author: Daniel Jose