Object responsibilities - list and item

Question

My question is more like a theoretical.

Say you have an object, that represents the list of something (articles, pages, accounts etc.)

class ObjCollection 

You have a class, that represents a specific item in collection:

class objItem

I have a problem thinking of a basic responsibilities of each object.

Which class is responsible for creating a new objItem?

Which class is responsible for deleting a objItem? Should it delete itself as a method?

---

Update 1: Techpriester: Is it ok to use object's constructor as a function to create new item? I think of that like:

class objItem {
    public function __construct($id = 0) {
        if ($id > 0) {
            // load item data...
        } else {
            // make new item...
        }
    }
}

But what if something goes wrong in the code, and instead of passing an $id > 0, it passes 0? In this case a more expected behavior would be an empty object, and not the new one, or am I wrong?

Answer 1

A way of thinking about this:

objItem usually have a class constructor so this class might be responsible for creating objects of type objItem.

When an objItem is inserted in a list/collection let's say objCollection it can be objCollection responsability to delete it from the collection.

Answer 2

Since an object cannot delete itself, that has to be the responsibility of the collection.

Wether you let the collection create it's objects like $collection->makeNewItem(); (which then calls the items constructor) or use $item = new Item(); directly and then some $collection->addItem($item);method is entirely up to you and the needs of your application.

I'd recommend using regular instantiation if the items themselves are also used outside of the collection.

Answer 3

objItem usually have a class constructor so this class is responsible for creating objects of type objItem.

Constructor has nothing to do with responsibility (usually). Thinking this way, every object would be only responsible for itself.

Responsiblity is a concept not directly binded with class hierarchy.

If:

ObjCollection = Nest objItem = Egg. And there is third object Bird, Then Bird takes responsibility for creating egs (even if nest contains egg). It is not about programming it is about common sense... :)

There is not such thing like "empty object". Objects have "state". You can create an object and then you have it, or you may not to create it and there is no object then.

All you have to worry about is if your constructor will work fine in both cases, with new object created and without it.

Usually it is better to inject object as a constructor parameter (instead of $id) not to create it inside another object.

Answer 4

I know this doesn't answer your question, but since you tagged this as PHP I'm going to assume that it will almost certainly be applied with some sort of database model.

In that case, it's probably a better idea to do away with 'collections' altogether since if you made each class represent only one object, if you wanted to view 10 blog posts, for example, you would be calling 10 separate SELECT queries each retrieving only an individual database record, because you decided to have the 'BlogPost' class encapsulate its retrieval method.

The alternative is to let the class represent either one or more records, that way, you only need to run one SELECT query whether you're retrieving 5000 records or only one. Pretty much every object-relational-mapper does this.

When doing object-oriented programming, it's better to think in terms of behavior or responsibility than whether or not the object is a tangible 'thing'. That's the problem with theoretical discussion of OOP. It's very tempting to use analogies like animals and fruits which have very little relevance to real-world programming.