Page 1 of 1

Return types, or types to return..

Posted: Tue Aug 22, 2006 7:54 am
by Jenk
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]

Posted: Tue Aug 22, 2006 7:59 am
by feyd
Simple answer: Object Oriented Programming.

:)

Posted: Tue Aug 22, 2006 8:06 am
by Jenk
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? :)

Posted: Tue Aug 22, 2006 8:24 am
by feyd
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.

Posted: Tue Aug 22, 2006 9:36 am
by sike
i would stick with returning whatever fits your needs.
if i need to use your class i could decorate/extend it to return whatever i need (:

cheers
Chris

Posted: Wed Aug 23, 2006 7:14 am
by Chris Corbyn
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)

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);
    }
}