A bit of an ambiguous title, apologies..
In examples such as d11's fabulous MySQL and Result Iterator class(es) we see an object returning it's value in a predefined type. In that specific case, the DB_Result object.
I've always designed my objects/classes with the intent of as much flexibility as possible, such as can be seen in my PHP5 Paginator - originally set to accept iArrayObjects but later changed to use primitive Arrays, and also it only returns arrays. It was suggested that the data be returned in an iterator..
However, I'm of 'the belief' that if I, or another developer wishes for that data to be an Iterator, they can do it themselves by either creating an Iterator object of their choice, or looping through the returned value.
However - this has now, in my infinite boredom at work, got me thinking.. which is the "better" practice? return a predefined type and assume the data will always be used in an iterator fashion, or return the data as a pritive type (where possible) leaving it open for as many possibilities as .. possible?
Have I got the wrong/right end of the stick with regards to OOP/D?
The reason I ask, is because lets say I was to use d11wtq's class(es) in conjunction with my paginator, I would then have to rework one or the other to be able to plug my paginator on to the result set.
[/random train of thought babble]
[back to learning about project design]
Return types, or types to return..
Moderator: General Moderators
That part I get, but what if they (the developer) wishes for it to be a different object? 
I know the simple answer for that is: they'll have to rework the class, and it's impossible to predict every and any usage and so forth.
but does it not make sense to make it as easy or flexible as possible from the start?
I know the simple answer for that is: they'll have to rework the class, and it's impossible to predict every and any usage and so forth.
but does it not make sense to make it as easy or flexible as possible from the start?
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
A few possible routes:
- have a method where each individual value is sent (possibly with name) so that they may overwrite that method with their own variant.
- have a method where they can give an object or class name that decends from some interface so they can accumulate it however they like into that object.
- stick with returning an array and force the developer to build a separate object.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
You could set up the db class to use some sort of injection/factory (I don't know the techincal term for this) like this:
(I'm only including sketches of the parts that provide the functionality)
(I'm only including sketches of the parts that provide the functionality)
Code: Select all
interface iResultFactory
{
/**
* Return something based upon a given result
* @param resource MySQL result
* @return {anything}
*/
public function createFrom($result);
}
class DB
{
private $resultFactory = null;
public function loadResultFactory(iResultFactory $obj)
{
$this->resultFactory = $obj;
}
public function query($query)
{
$result = mysql_query($query);
if ($this->resultFactory === null) return new DB_Result($result);
else return $this->resultFactory->createFrom($result);
}
}