对象职责 - 列表和项目

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

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.