Design thoughts ... category display its own class, or method of individual objects?

dalecosp

So, you have "products" and you have them in categories. Is the "category list" typically its own class method, or does each "product" object know how to display itself in a category list?

Approach the 1st:

class Category {

   public blah, blah...

   function display() {

   //select from the DB

   //write or return formatted HTML

}

And the other way:


class Category {

   public blah, blah...

   function display() {

  foreach ($this->category_list as $product_code) {

     $item = new Product($product_code);
     $item->display();

  }
}

The second seems like it'd be "cleaner", easier-to-read and such, but I'm balking at the idea of creating $n-hundred objects for every page load.

Thoughts? I suppose there might even be more ways to skin this cat? Thanks in advance!

NogDog

My first inclination is to keep anything to do with HTML output away from your Category class. I might provide a method that returns an array of pertinent data, which can then be used directly in a view or template page, or perhaps supplied to some function (part of a HTML helper function include file or method in a HTML class, perhaps?), that would generate the actual HTML that you want. Unless I misunderstand the purpose of the Category class, you don't want to have to mess with it (and any other similar classes) when someone decides to change the structure of the HTML.

dalecosp

That's more or less the approach I've taken. I suppose I'd read someplace that everything about an "object" should be encapsulated in that object, so I was wondering if

$product->display();

was a "correct" approach ... it didn't seem like common sense, though.

I might provide a method that returns an array of pertinent data, which can then be used directly in a view or template page

At present, I've got a method in the Category class that's returning a multi-dim array for the template to use. Perhaps I've got OK instincts after all 😃

Thank you, Nogdog. 🙂

Weedpacket

dalecosp wrote:
I suppose I'd read someplace that ... it didn't seem like common sense, though.

Well, the principle still holds: consider that how a Product is displayed has less to do with the Product and more to do with the display mechanism.

My thinking (and apparently it's called MVVM) has been to develop an object model for presentation (what MVVM calls a "View Model"): a set of objects distinct from the objects of the entity model. the presentation model is geared towards how things are displayed in a particular setting, without necessarily being tied 1:1 with the entities. Presentation objects are used only in the view layer and entity objects only appear in the view layer as arguments to presentation objects (usually during instantiation) - all access to the entities is mediated through the presentation model.

On a somewhat related note: I find that if I'm dealing with collections of Foo objects as collections, I might define a generic FooCollection class to hold the relevant methods, and subclass it for specific types of collection.