Observer Pattern - page 2

New comment
 
Amir Yacoby:
This implimentation of observer is useless without multi inheritance.

What? Why do you say that? There is only one interface to implement.
 
nicholishen:
What? Why do you say that? There is only one interface to implement.
Because the observer pattern needs to be inherited by your classes in order to operate (you have to inherit CObserver on one side and CSubject on the other) but your classes are already decendents of some generation of CObject.
Lets say you have a trading class of some kind of CTrade and a gui class of some kind of CLine. And you want the trading object to listen to the events of the line, for instance to act when the price crosses the line. 
The CLine is a decendent of CObject so it cant be also a CSubject (to notify its cross event) and the CTrade is also a decendent of CObject so it cant be also an observer.


 
Amir Yacoby:
Because the observer pattern needs to be inherited by your classes in order to operate (you have to inherit CObserver on one side and CSubject on the other) but your classes are already decendents of some generation of CObject.
Lets say you have a trading class of some kind of CTrade and a gui class of some kind of CLine. And you want the trading object to listen to the events of the line, for instance to act when the price crosses the line. 
The CLine is a decendent of CObject so it cant be also a CSubject (to notify its cross event) and the CTrade is also a decendent of CObject so it cant be also an observer.


An observer subclass does not inherit from Subject, only from Observer. The observer list (member of Subject) stores object pointers of Observer subclasses. No multiple inheritance required. 


Edit: I do however see what you are saying about using std lib classes. In order to get around this you'd need to clone the class into a local project folder and change its declaration to:

#include "observer.mqh"
class CLine : public CObserver

instead of 

class CLine : public CObject
 
nicholishen:


Edit: I do however see what you are saying about using std lib classes. In order to get around this you'd need to clone the class into a local project folder and change its declaration to:

instead of 


Well, that's why it's useless. You will have to copy all the classes in between CObject and CLine into CLine source and make it one class and then inherit CObserver.

Edit: The minimum metaquotes should have allowed is to make the interface implementation an addition to class inheritance. Because now interfaces are useless.

 
Amir Yacoby:

Well, that's why it's useless. You will have to copy all the classes in between into CLine source and make it one class and then inherit CObserver.


It would literally take less than a minute to copy/paste files and change the declaration, so if you consider a minor inconvenience to be "useless" then so be it...

I really don't get the mindset that MQL projects are best kept to a single source file...

 
nicholishen:

It would literally take less than a minutes to copy/paste files and change the declaration, so if you consider a minor inconvenience to be "useless" then so be it...

I really don't get the mindset that MQL projects are best kept to a single source file...


No, I don't understand you. 
If you are using GUI in your projects, than you really can benefit from observer pattern (not only in GUI, but in GUI it's most obvious) - In that case any graphical object of type CChartObject can be a subject that informs events to different trading objects that act as observers. The observer pattern combined with OOP should give you the ability to take each trading class in your set of classes and instantly make it an observer and take each CChartObject and make it a subject - You mean to say that I need to ruin all the class hierarchy in order to use this and it's still acceptable?

In my case, this pattern should be used extensively across the board of classes when it's available.

 
Amir Yacoby:

No, I don't understand you. 
If you are using GUI in your projects, than you really can benefit from observer pattern (not only in GUI, but in GUI it's most obvious) - In that case any graphical object of type CChartObject can be a subject that informs events to different trading objects that act as observers. The observer pattern combined with OOP should give you the ability to take each trading class in your set of classes and instantly make it an observer and take each CChartObject and make it a subject - You mean to say that I need to ruin all the class inheritance in order to use this and it's still acceptable?

I agree with you that multiple inheritance would be much more convenient, however, you do not need to "ruin" inheritance in order to implement.

Clone ChartObjects folder to project subfolder.
class CObserver : public CObject
class CChartObject : public CObserver

Now all ChartObject subclasses have inherited both CObject and CObserver 

 
Exactly
 
nicholishen:

I agree with you that multiple inheritance would be much more convenient, however, you do not need to "ruin" inheritance in order to implement.

Now all ChartObject subclasses have inherited both CObject and CObserver 


Well, it's a step forward, but not enough, because I want all my classes to be able to observe or inform as they like. 

But what you say is a step in the right direction. The better solution (credit goes to #Doerk Hilger) is to make the CObject also an obsever/subject.
 
Amir Yacoby:

Well, it's a step forward, but not enough, because I want all my classes to be able to observe or inform as they like. 

But what you say is a step in the right direction. The better solution (credit goes to #Doerk Hilger) is to make the CObject also an obsever/subject.

Yes, that's a pretty obvious solution, however, it'll break every time your terminal updates and the Object.mqh file is replaced with the default CObject. 

123
New comment
Reason: