[Typo3-dev] singletons instead of pre-loaded objects

[Leendert Brouwer [Netcreators]]

> Well, okay. Objects are not the real problem, I think. And I do grasp
> all the nice examples out there about cars having parts and
> methods. But, honestly, what gives me trouble are mostly those two
> things (maybe, as soon as I 'got' those, it'll all fall in to places):
>
> 1. Fetching a list of items from a DB
>
> Say we have a list of contacts to fetch. Each contact is an object
> (with attributes like name, address, ... and getter/setter methods for
> those). So, I could just 'select * from' and iterate over the result
> set. Where do I place this in the OO world? Do I create another object
> like ContactList that has methods like fetchAll() or searchFor()?

Yes, that's a fine approach. ContactList will then hold a number of Contact
objects. A lot of PEAA patterns related to this topic that you can use -
look at "Data Source Architectural Patterns" in the catalog here:
http://www.martinfowler.com/eaaCatalog/ For these things, an OR-mapping (OR
= Object Relational) framework is often used in Java. There's one for PHP
here:  http://propel.phpdb.org


>
> 2. Saving items to the DB
>
> I instanciate an object. Fine, now set some attributes, call some
> methods. Now I want this to be stored in the database. It seems as if
> calling a method saveToDB() is a bit awkward? Or is it a Good
> Thing[tm]? Would it be better if objects that are supposed to be
> persistent would store themselves automatically on destruction? And
> what about deleting? Would I call deleteFromDB() on an instance?

You are of course free on how to implement it. Generally you just use what
makes the most sense for your particular application. It's quite common to
e.g. name those methods delete() or update() or save() or whatever. I
wouldn't call it "saveToDB", a "client" of the class (an object calling
methods on an instance of that class) does not need to know about storage
specifics, so "ToDB" is irrelevant. But without getting pedantic, yeah,
that's how it's done.

>
>
> And there's the question on how exact one follows the model one has
> come up with. Say we have users and administrators - naturally two
> classes, the administrator just having more rights. In 'real life',
> I'd never create two classes, but just add a flag isadmin to the user
> class and add an isAdmin() method. Is this good, bad or nonsense?

Adding a flag is good. However, when an administrator starts to differ more
from a regular user, things tend to get out of hand. That's when refactoring
peeks in. The 'art' of refactoring is basically that when you need to add
changes, you add the change to your object design as well. So in the current
case, when you notice there are more and more differences, you could apply
the "Extract Subclass" refactoring:
http://www.refactoring.com/catalog/extractSubclass.html. Basically you'd
then make Administrator a subclass of User (an Administrator "is a" User,
that's why Administrator can be a subclass of User, the reverse does not
hold true, a User is not per definition an Administrator).

>
> Sorry for the long post (and the maybe silly questions :).

No such thing as silly questions. It can take a while before OO theory
becomes natural, I'm aware of the learning process.

> PS: Seems as if the refactoring article you mentioned isn't available
> online... :(

Ah ok. Then it's only available in print I guess. I have it lying around at
home in a .txt file, but I'm not sure about copyright restrictions, I'll
have to figure those out first.

Regards,

Leendert