PHP – Best Practices for Returning an Array of Objects

object-orientedPHP

If I have an ItemContainer class that contains, for example, items in an order, where each item is an Item object; is it best to have a method like:

ItemContainer->getItems()

that returns an array containing Item objects, or is it better practice to do something like:

ItemContainer->getItem($itemNo)

which returns a single item object for that item number, and forgoes the array. I realise this may be a trivial question or simply one of preference, but I'd like my app to adopt best practices from the start and I'm unsure which way to proceed. I'm writing in PHP, but I figured this pretty much applies to any OOP language.

Best Answer

The principle reasons for not following the ItemContainer->getItems() approach and returning an array are:

The initial implementation is likely to just return a reference to the original array, which would then allow the caller to modify the underlying collection. This is considered bad practice.
The next work around is then to make a copy of the array and return that instead. This is bad because a caller may think they are still modifying the underlying collection, and it is also expensive for large collections.

If the caller really wants to have a copy of the array, then itemContainer->cloneItems() is much clearer, and less likely to be used inappropriately.

If the caller is just wanting to have a single item, then providing a

itemContainer->getItem(index && key)

is clear and efficient

If the caller is wanting to iterate over the items, then providing a

itemContainer->getItemIterator()

is clearer. Depending on the language you may implement

itemContainer->VisitItems(visitor)

where visitor is a visitor class, delegate or function pointer.

Hopefully, I've given you some ideas on how this can be approached differently

Related Solutions

PHP Object-Oriented – Multiple Object Instantiation Best Practices

Creating 100, 1 000 or 10 000 similar objects is not itself an issue (unless the object itself is huge). If you find yourself creating thousands and thousands of objects, ask yourself if you really need to.

If you're loading Cat objects, one per cat stored in the database, do you need to load all the 500 000 cats, for example? Why? You can't display them on the screen: it wouldn't be particularly useful. If you need to process them, is preloading everything the best way to do?

When you need a list of black cats, you don't load every cat available. What you do is to limit, at database level (for example with a where [color] = @color), the results you get, and you build objects corresponding to black cats only.

Indeed, this can be done in a factory which will contain a method which takes a specific color and returns the cats of this color.

Doing a query per cat, on the other hand, is a terrible approach. The fewer queries you do, the better. That's why your suggestion to use a factory was a good idea.

Java – OOP Objects, nested objects, and DAO’s

Should I be nesting one object as part of another or should I be creating more specific objects for different usages.

Follow OO principles first which means "more specific objects." In doing so your classes may "line up" with your database schema or not but do not let DB schema trump good OO design.
Single Responsibility Principle will help guide you in what classes to build. SRP means, for example, that a Song is a song. It is not an artist, it is not a list of subscribers, so it should not have artist or subscriber stuff in it. Only song stuff.
The above means that you will have lots of small, independent, fully functional things - classes. By "fully functional" I mean, if a Song is a name, date, and id then that's what's in it. period. The fact that a certain artist sings that song does not inherently, fundamentally define what a Song is. This means other classes to model relationships like "an artist's song repertoire" for example.
Small functional classes leads to good DAO's and flexibility for your user interface.

Option 1 means wasting a lot of time/resources grabbing information I may not need for that page but easier to manage. Option 2 is messy and requires keeping track of which object is what but faster and far less db calls

You are falling victim to premature optimization. How can you know up front that option 2 will have "fewer DB calls?" What does that mean anyway?
This is simply the wrong way to think about your domain classes/model. This is why you end up duplicating your DB schema:

Class SongWithArtist {
  private $song; //Basic Song object
  private $artist; //Basic Artist object
}

When what you should have is something describing the real world:

Class ArtistPortfolio {
    private Artist $theArtist;
    private List<Song> $portfolio;  // list of songs (s)he sings 
}

Class ArtistSubscribers {
    private Artist $theArtist;
    private List<User> $subscribers;  // list of people who like this artist
}

// And it would probably make sense to combine the above 2 classes:

Class ArtistProfile {
    // an Artist object, not just an id. We're doing OBJECT oriented programming.
    private Artist $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

// and if you need a list of profiles...
Class ArtistProfiles {
    private List<ArtistProfile> $profiles; // a list of type ArtistProfile

    public ArtistProfile GetProfileByArtist (Artist thisArtist){}
    public ArtistProfile GetProfileByName (string name) {}
    public ArtistProfile GetProfileById (string id) {}
}

// I'd say a ArtistProfile could be part of an Artist..

Class Artist {
    private $id;
    private $name;
    private ArtistProfile $profile; // this is composition.
}


//In lieu of the above, an DAO oriented Artist composition ...
// Just go with the refactoring flow!
Class Profile {
    private $id;
    private $name;
    private $birthdate
}

 Class Repertoire {
    // a Profile object, not just an id. We're doing OBJECT oriented programming.
    private Profile $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

Class Artist {
    private Profile $me;
    private Repertoire $myStuff; 
}

Too Many DB Calls!

NOT. You can instantiate a Artist object without populating the $myStuff and in turn, defer populating $subscribers / portfolio lists until needed. This is called lazy loading.

Best Answer

Related Solutions

PHP Object-Oriented – Multiple Object Instantiation Best Practices

Java – OOP Objects, nested objects, and DAO’s

Related Topic