Page 1 of 2

Using $this->owner - wrong or right?

Posted: Wed Aug 22, 2007 10:24 am
by VladSun
Hello, everybody!

Suppose we have two classes - TForm and TInput. TInput has a property called owner which points back to the containing TForm instance. The use of having this is that I have a TForm string property called CSS_Class which I can use it (by $this->owner->CSS_Class) when drawing TInput elements, instead of having CSS_Class property for each TInput (and setting it).

But it seems to me that it is a wrong approach to have back reference to the owner object. On the other hand, HTML FORM object is the owner of INPUT object, so I have a closer model.

What's your opinion?

Posted: Wed Aug 22, 2007 10:28 am
by feyd
Sounds like someone came from Delphi. :)

TForm should interrogate TInput for the class it wishes to use.

Posted: Wed Aug 22, 2007 10:32 am
by VladSun
feyd wrote:Sounds like someone came from Delphi. :)
I've never written even a single line code in Delphi ;)
It's the Pascal 6.0 style ;)
feyd wrote:TForm should interrogate TInput for the class it wishes to use.
So you think this apporach is wrong? But why?

Posted: Wed Aug 22, 2007 10:37 am
by feyd
Objects should generally have no knowledge of their owners. They need to be as loosely coupled as possible. This may entail implementing an standardized interface between them to the various objects could be connected to any number of other objects supporting that interface.

Posted: Wed Aug 22, 2007 10:54 am
by VladSun
So, if I implement TForm method set_CSS_Class, which calles the corresponding TInput set_CSS_Class for each TInput in the inputs collection, it would be closer to OOP?

Posted: Wed Aug 22, 2007 10:57 am
by VladSun
Hm, I have a second case ... Imagine that every TInput cant fire an TEvent, which should be handled by method handle_Event by all of the objects (including TForm) in the owner ...

Posted: Wed Aug 22, 2007 11:03 am
by feyd
VladSun wrote:So, if I implement TForm method set_CSS_Class, which calles the corresponding TInput set_CSS_Class for each TInput in the inputs collection, it would be closer to OOP?
Potentially. It's hard to say without seeing code.
VladSun wrote:Hm, I have a second case ... Imagine that every TInput cant fire an TEvent, which should be handled by method handle_Event by all of the objects (including TForm) in the owner ...
It sounds like you are describing an Observer/Observable (or Subscriber/Publisher) Pattern. That is often how events are handled at any rate.

Posted: Wed Aug 22, 2007 11:07 am
by VladSun
feyd wrote:It sounds like you are describing an Observer/Observable (or Subscriber/Publisher) Pattern. That is often how events are handled at any rate.
Is it done by having owner (or similar) property in each object?

Posted: Wed Aug 22, 2007 11:12 am
by feyd
VladSun wrote:Is it done by having owner (or similar) property in each object?
Typically, no. The object that is being watched has a method called update() or something similar. It returns some standardized information based event information.

Sometimes it is implemented as a listener's list where the object maintains a list of listeners that it calls when an event (or a specific event, depending on how details the listener system works) stating "I've had an/this event! Do whatever you need to do."

Posted: Wed Aug 22, 2007 11:40 am
by VladSun
Thank you for participating in this discussion :) !

So, when using this->owner approach we have asynchronous events, while using other approaches we have synchronous events? Is that correct?

Posted: Wed Aug 22, 2007 11:43 am
by feyd
In PHP, they're pretty much always synchronous.

Posted: Wed Aug 22, 2007 12:00 pm
by Christopher
VladSun wrote:So, if I implement TForm method set_CSS_Class, which calles the corresponding TInput set_CSS_Class for each TInput in the inputs collection, it would be closer to OOP?
There are a couple ways to deal with this. You might want to look through some likely patterns and see which one is a solution to the specific problem you have. In general you don't want references back to the parent, the exception is when the class does not know that the link is to the parent (i.e., there is no hard dependency), but the parent initializes the child and passes an object to the constructor or a setter. Then the dependency is to a specific external interface. The parent can pass $this or some other object.

I would recommend that you extract CSS_Class from both TForm and TInput. That would probably be the cleanest. feyd's Observable suggestion is a good one too.

Posted: Wed Aug 22, 2007 5:02 pm
by VladSun
feyd wrote:In PHP, they're pretty much always synchronous.
You got me :oops:

Indeed, I asked it because I have one big JavaScript application (2500-3000 code lines, full OOP) and I am trying to reimplement it according to the MVC ideas.

Posted: Wed Aug 22, 2007 5:06 pm
by VladSun
arborint wrote:... the exception is when the class does not know that the link is to the parent (i.e., there is no hard dependency)...
You mean, the class should not depend on the type of the parent class? I.e. the class will always rely on the existence of some methods in the parent?
arborint wrote:but the parent initializes the child and passes an object to the constructor or a setter. Then the dependency is to a specific external interface. The parent can pass $this or some other object.
That's what I do for now.

Posted: Fri Sep 07, 2007 5:43 pm
by VladSun
I'm still interested in finishing this discussion :)

And let me reword the question - "When it is suitable to have references back to the parent (owner)?"