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

[Leendert Brouwer [Netcreators]]

Hi Karsten,

> I'm struggling myself when it comes to 'proper' or 'real' OO - I just
> don't get it sometimes. Patterns and stuff - fine, but what if I just
> need to output some data from a database? Really, this is where I
> often struggle...

Then you just output some data from a database ;) It is a misconception that
you _have_ to use patterns to use proper OO. Patterns should be applied
naturally, and maybe you are already applying patterns but just never read
about them (a lot of people use Front Controller for instance, without
knowing it). Reading about them helps, and once you've read about them, you
will find yourself in situations where you think "wait a minute, I've read
about this situation, there's a common, proved solution to this problem".
And that's where you can consciously apply a particular pattern.

>
> Since this is probably my fault - could you give some nice examples
> where the design of TYPO3 is bad, and how it could be improved? To me
> it looks quite OO, to be honest. Lots of classes, nicely encapsulating
> methods, fetching an instance my makeInstance(), ...

Just to scratch the surface, know that in OO, an object actually has to
represent an object (and that is less of a "duh"-moment than it might seem
sometimes). The object represented should be as complete as is needed for
the implementation of the object. Let's pick a random TYPO3 class. The one
for representing a backend user for example. It's called t3lib_beUserAuth.
Not t3lib_beUser. Not t3lib_BackendUser. Ok, that's just the name. But for
new developers, reading through the code should be intuitive. So
t3lib_BackendUser would be the most descriptive. Let's look on further.
t3lib_beUserAuth inherits t3lib_userAuthGroup. That looks impossible from an
OO point of view. A person (backend user) inheriting the behaviour and
properties of a group (backend user group). A user is not a group. In OO
terminology: a user does not have an "is-a" relationship with a group. In
this case, t3lib_userAuthGroup (t3lib_BackendUserGroup?) should hold an
aggregate of t3lib_beUserAuth objects, most likely. A group is composed of
users, like a song is composed of notes (see how natural it feels?). I could
go on for hours, but I don't think anyone likes this kind of criticism. But
I hope you see what I mean. There are many  flaws like this (and many
others) in the TYPO3 architecture. Classes of more than 500 lines are
suspicious by default. They are likely to contain much more responsibility
than an object should have. 9 out of 10 times, such classes can be more
easily decomposed into smaller classes. And maybe those smaller classes can
be reused by other classes, thus avoiding duplicate code and provoking
abstraction and loose coupling. Like I said, I could go on for hours.

>
> Just because it doesn't use patterns, is it bad OO? Again: I'm
> *really* interested in this, as I suspect 'proper' OO *is* better than
> what I do most of the time (not talking about TYPO3 now).

No no, you don't _have_ to use patterns, that's definitely a misconception.
You have to be able to think in objects. That's when you implement the
objects. Naturally. Maybe my article here can help you a bit with that:
http://www.php-mag.net/itr/online_artikel/psecom,id,284,nodeid,114.html .
Once you think in objects, patterns can help you, and you'll even be free
and able to invent your own patterns. Not first patterns and then object
thinking. Other way around :)