Help with pseudo multi inheritance - page 4

 
nicholishen:

I beg to differ, I am in fact not wrong.

No classes were "lost" and the implementation inheritance is the exact same as using multiple inheritance. 

No.

1. There are classes lost if CTrade folder does not include all the classes between CObject and the desired class. It is not the case in real life. 

2. If you make CTrade an observer descendent - you can not make any of it's sub-classes a subject.

Well, it is for me a really really bad solution, and it makes the use of observer non relevant.
There are better solutions still.

 


nicholishen:
 

I feel like something is getting lost here... Are you using an English translator? Do you understand what it means to clone a class/folder into the project directory?

No translator, but always open to learn if I miss something.
What does it mean?

 
Amir Yacoby:

No.

1. There are classes lost if CTrade folder does not include all the classes between CObject and the desired class. It is not the case in real life. 

2. If you make CTrade an observer descendent - you can not make any of it's classes a subject.

Well, it is for me a really really bad solution, and it makes the use of observer non relevant.
There are better solutions still.


Seriously? lol

Sometimes you gotta think outside of the box... just change the class name to "CTradeObserver" and/or "CTradeSubject". Nothing breaks, you can still use std CTrade, and it took you all of about 3 seconds to type.

 
nicholishen:

Seriously? lol

Sometimes you gotta think outside of the box... just change the class name to "CTradeObserver" and/or "CTradeSubject". Nothing breaks, you can still use std CTrade, and it took you all of about 3 seconds to type.

What?

You don't get it because CTrade is a bad example.
Let's take CLine.

It's derived from (in my framework)
CObject > CTimePrice > CChartObjects > CTrendLines

Now - in order to make CLine a subject, you tell me to copy CTimePrice folder with all it's subclasses to a project folder and make it derive CTradeSubject.
But what if I have another class under it that wants to be an observer? What you do is commit the first decendent of CObject to be either a father of Observers or of Subjects - with no option to switch.

This is bad design, bad solution for me. If you are happy, go ahead. I don't care.

 
Amir Yacoby:

What?

You don't get it because CTrade is a bad example.
Let's take CLine.

It's derived from (in my framework)
CObject > CTimePrice > CChartObjects > CTrendLines

Now - in order to make CLine a subject, you tell me to copy CTimePrice folder with all it's subclasses to a project folder and make it derive CTradeSubject.
But what if I have another class under it that wants to be an observer? What you do is commit the first decendent of CObject to be either a father of Observers or of Subjects - with no option to switch.

This is bad design, bad solution for me. If you are happy, go ahead. I don't care.


Like I said, rename your classes. Ctrl+C class-name, Ctrl+H new-class-name, replace all. Takes a few seconds. Less convenient, yes. But it works, period. Or just use a wrapper. Either way; two viable methods for inheriting the appropriate interfaces.


It should go without saying that since you created a "CTradeObserver" that you would also create a separate "CTradeSubject". This much is obvious, and I shouldn't have to spell it out :(

 

This is exactly what Alain said, it has limitations that are not part of the subject/observer design - just because multiple inheritance is absent.
This is functional limitation.
But there are also usage limitations, because I want (and actually do in my case) not make any changes at all and if I am coding a class that needs to observe a line or a Fibo object or whatever, I just want to code it straight forward without shifting folders and so on. 

 
Amir Yacoby:

This is exactly what Alain said, it has limitations that are not part of the subject/observer design - just because multiple inheritance is absent.
This is functional limitation.
But there are also usage limitations, because I want (and actually do in my case) not make any changes at all and if I am coding a class that needs to observe a line or a Fibo object or whatever, I just want to code it straight forward without shifting folders and so on. 


At least we're making progress, and we both agree on my original point: It's less convenient, but same net result as multiple inheritance. 

 
nicholishen:

At least we're making progress, and we both agree on my original point: It's less convenient, but same net result as multiple inheritance. 

But you suggest that if I have a subclass that wants to be observer and another that wants to be subject and they have same super-class then make two super-classes.
One for observers and one for subjects.

This means maintain two sets of exactly duplicate set of classes just with different father.

No thanks. Works, yes. This is the only progress we made (:  Usable or even considerable, not for me.

There are better solutions, even without multiple inheritance.
 
Amir Yacoby:
But you suggest that if I have a subclass that wants to be observer and another that wants to be subject and they have same super-class then make two super-classes.
One for observers and one for subjects.

This means maintain two sets of exactly duplicate set of classes just with different father.

No thanks. Works, yes. Usable or even considerable, not for me.

There are better solutions, even without multiple inheritance.

Agreed, but we weren't talking about other patterns. You said that it was "useless" without multiple-inheritance and a workaround would come with consequences. We found a workaround without consequences (other than inconvenience) that performs the same as multiple inheritance. 

 
nicholishen:

Agreed, but we weren't talking about other patterns. You said that it was "useless" without multiple-inheritance and a workaround would come with consequences. We found a workaround without consequences (other than inconvenience) that performs the same as multiple inheritance. 

Well, we can debate if dulplicating and maintaining dozens or hundreds of classes and maintain those two sets of duplicate is not a consequence in order to use the observer pattern, but we have better things to do (:

Reason: