Return types, or types to return..

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Return types, or types to return..

Post 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]
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Simple answer: Object Oriented Programming.

:)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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? :)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
sike
Forum Commoner
Posts: 84
Joined: Wed Aug 02, 2006 8:33 am

Post 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
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

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