Using $this->owner - wrong or right?
Moderator: General Moderators
Using $this->owner - wrong or right?
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?
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?
There are 10 types of people in this world, those who understand binary and those who don't
I've never written even a single line code in Delphifeyd wrote:Sounds like someone came from Delphi.
It's the Pascal 6.0 style
So you think this apporach is wrong? But why?feyd wrote:TForm should interrogate TInput for the class it wishes to use.
There are 10 types of people in this world, those who understand binary and those who don't
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Potentially. It's hard to say without seeing code.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?
It sounds like you are describing an Observer/Observable (or Subscriber/Publisher) Pattern. That is often how events are handled at any rate.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 ...
Is it done by having owner (or similar) property in each object?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.
There are 10 types of people in this world, those who understand binary and those who don't
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Typically, no. The object that is being watched has a method called update() or something similar. It returns some standardized information based event information.VladSun wrote:Is it done by having owner (or similar) property in each object?
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."
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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?
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.
(#10850)
You got mefeyd wrote:In PHP, they're pretty much always synchronous.
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.
There are 10 types of people in this world, those who understand binary and those who don't
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:... the exception is when the class does not know that the link is to the parent (i.e., there is no hard dependency)...
That's what I do for now.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.
There are 10 types of people in this world, those who understand binary and those who don't