Page 1 of 1

Casting object to another class

Posted: Sat Mar 28, 2009 10:06 am
by crazycoders
Hey there, this is more theory and design than a question because i think there are no perfect solution, so i'll explain what i'm trying to do and you tell me what you think...

I have a library used to manage data using drivers and objects called:

datatable
datacolumn
datarow
idataadapter
mysqldataadapter
arraydataadapter

Now i have a class called gridview which is used to create a full featured grid component in html. All of this is in dev right now but here is where i bug.

When i receive the data in the gridview control, i wish to be able to extend the datacolumn class to create gridviewcolumn class. This class extends the datacolumn because i wish to keep the datacolumn rules and functionnalities close to me. The newer class adds display properties relative to the column. When i loop the $dataset->columns() array, i receive all the datacolumns objects, i wish i could simply cast them to gridviewcolumn which extends the already existing datacolumn...

PHP doesn't support casting objects to other object types even in a scenario where the target type would be an extension of the current type.

So we have 3 scenarios:

Code: Select all

$mycolumn = (gridviewcolumn)$datacolumn; //Doesn't work because PHP doesn't support it at all, what a shame
$mycolumn = new gridviewcolumn($datacolumn); //Version 1 implements stub functions that call a reference to the datacolumn
$mycolumn = new gridviewcolumn($datacolumn); //Version 2 reimplements and copies the info from the column and discards it (Not effective)
$mycolumn = new gridviewcolumn($datacolumn); //Version 3 implements gridview specific properties and keep a copy of the data column somewhere and the code must ask for the datacolumn through a property accessor (probably the best way)
Requirements:
- Keep the objects in one copy only, for example, i dont' want to clone objects and create a new copy of it, the goal is to limit processing and memory usage while still allowing the best access/extension methods

Scenario 1
is impossible, lets forget it, although it would have been the best solution, maybe i could submit a patch for php5 and php6 :)

Scenario 2,3,4
We could still extend the datacolumn but is a bit useless because the constructor would require the instance to be rebuilt and what we wish to achieve is keep the same reference all around the application without cloning the objects, so the new gridviewcolumn class should not extend the datacolumn class.

Scenario 2
We could implement stub functions to call the datacolumn's properties and functions of the datacolumn object that we keep a reference to inside the class. Problem with this is that if the datacolumn changes we could need to change the gridviewcolumnn to mimic the changes in the stub functions.

Scenario 3
Simply create a new class that copies the information and mimics the effect of the column class. In my opinion, doing that defeats the objective of OO programming where encapsulation and reuse plays a primary role. Too much work if there is a bug in the column class and prone to errors when trying to mimic the effect of the column class.

Scenario 4
Create a gridviewcolumn class that has the datacolumn property and returns it if the user wants to use it. The gridview can use it too easily because it is aware of the connection between the two. The only drawback i see is that to access the datacolumn object you need an additionnal step in your code, but scenario 2 does the same thing but hides it...

Ok, so what do you think? I'm really looking at S4 as my solution but i'd like your input on the subject...

Re: Casting object to another class

Posted: Sun Mar 29, 2009 12:57 pm
by josh

Re: Casting object to another class

Posted: Sun Mar 29, 2009 1:53 pm
by crazycoders
That doesn't help at all... thanks again your pattern approach examples...

Re: Casting object to another class

Posted: Sun Mar 29, 2009 2:10 pm
by josh
You start a thread about casting objects to another class in PHP. This isn't java. The state pattern ( an offshoot of the strategy pattern ) is the commonly accepted way to handle your design problem. This is the cliche example of "reinventing the wheel", OO design already handles this elegantly yet you feel the need to implement this in a relational paradigm instead

Re: Casting object to another class

Posted: Sun Mar 29, 2009 8:19 pm
by Christopher
I wouldnt't try to cast. I would have the dataset class have a property that specifies what the class of the objects returned is. The default would be ' datacolumns', but the grid class could set it so it returns a 'gridviewcolumn' class.

Re: Casting object to another class

Posted: Sun Mar 29, 2009 8:55 pm
by josh
arborint wrote:I wouldnt't try to cast. I would have the dataset class have a property that specifies what the class of the objects returned is. The default would be ' datacolumns', but the grid class could set it so it returns a 'gridviewcolumn' class.
Gridview and datacolumns class would be playing the roles of concrete state / concrete strategy

Here's a link thats probably a little bit easier to follow then wikipedia. http://www.ksc.com/article3.htm

This pattern also goes by the alias "power type"

Re: Casting object to another class

Posted: Sun Mar 29, 2009 10:32 pm
by Christopher
josh wrote:Gridview and datacolumns class would be playing the roles of concrete state / concrete strategy
I don't think it is State or Strategy. State allows behavior to change based on context; Strategy allow the algorithm to change. This is really probably following Factory if it is following a pattern. It is creational in that it allows classes that create child objects to create inherited children when the class itself is inherited -- but keeps the instantiation code in the base class.

Re: Casting object to another class

Posted: Mon Mar 30, 2009 6:21 am
by crazycoders
Don't bother guys, i decided to go with scenario #4 because i realized that my gridviewcolumns are not always bound to data, sometimes it's a custom control that must appear as per the user's choice, so idisconnected the gridviewcolumn type from the datacolumn type, because they are not intimately related anymore...

Thanks anyway

Re: Casting object to another class

Posted: Mon Mar 30, 2009 8:21 pm
by josh
The state pattern would be something like:

Code: Select all

 
class view
{
 function foo()
 {
   return $this->state->foo();
 }
}
 
$state = new view_state_gridview();
$view = new view( $state );
$view->foo(); // runs command on object of type gridview
$view->state = new view_state_otherview();
$view->foo(); // calls code on an object of a class other than the original gridview state
 

Re: Casting object to another class

Posted: Mon Mar 30, 2009 10:23 pm
by Christopher
josh wrote:The state pattern would be something like:
Yep.

Re: Casting object to another class

Posted: Mon Mar 30, 2009 10:31 pm
by josh
arborint wrote:Yep.
( I know you know what it is, I was posting at crazycoders who seems to be overlooking the solution due to a communications problem, hes rejecting the common accepted solution seemingly because it is a "pattern", yet if he was observant he'd see his term "scenario" means the same thing, and that he is reinventing the wheel )

Re: Casting object to another class

Posted: Mon Mar 30, 2009 10:34 pm
by Christopher
Sorry, I was agreeing that what you showed would be a better solution than crazycoder' scenario #4.

Re: Casting object to another class

Posted: Mon Mar 30, 2009 11:30 pm
by josh
Ah I thought we still were discussing strategy vs state. I use the terms loosely of course, the line is kind of blurry though.. and for me for some reason when i read the name of the strategy pattern it was really intuitive, I mean I knew what polymorphism was, but didn't thoroughly deeply understand how to use it in the ways it can really help, like crazycoders "scenario 4"... When I read about the strategy pattern it made a little more sense. Unfortunately when I try to explain to some coders in person they get all pretentious on me like "you dont think i know what polymorphism is?!?", its like calm down, be humble and learn, hah