[TYPO3-50-general] Helping Functions

[Nino Martincevic]

Hi Ries,

ries van Twisk wrote:
>> Which is, by the way, in most cases an "getter/setter anti-pattern",
>> sadly seen in far to many places, if used this way:
> 
> I don't think it's that sad at all.

You are right. It's worse than that ;-)

>>
>> private $bla;
>> function getBla() {
>>  return $this->bla;
>> }
>>
>> Why you have a getter if you set it private?
>> Or why you set it private when you provide a getter?
> 
> Because you don't want people to access the variable directly.

But what does this getter do?
Nothing else, it exposes a private property.
A clear violation of encapsulation.

> So when in feature the class get's extended and the $bla get's  
> calculated you are assured
> that people use the interface for the class rather then access vars  
> directly. A good example
> is TYPO3 and extensions where extensions often get some GLOBAL and do  
> 'something'.
> You totally loose control.

Did I really read GLOBAL? Jehova!!!!
;-)

Sorry for again drifting away from the thread but I cannot leave this 
standing that way.

Ok, you talk already about getters that a priori will be extended or are 
intended to be. But why someone should access vars either, why not use 
the provided responsibility of that class by calling methods that 
provide them?
And an objects meaning is not to access its properties, but to use its 
behaviour and let it do what it can do best.

An interface that works with exposing its internals is dangerous per se.
Change the implementation behind are its broken, because you are using 
assumptions with getters that may change.

That's why you should avoid getters where possible and it make sense, 
but instead replace it with behaviour. Aside from being a class only 
serving as a data container.

First you should think about what your getters are really doing and how 
you could avoid them by providing behaviour instead.

Here's a classical example:

$list = $someObject->getArticleList();
$list->addElement($foo->getKey(), $foo);

What do you expose here?
1. someObject manages its articles in a list
2. the method to add artciles is addElement
3. $foo's way to get its key $foo->getKey(), which btw. is another 
violation of TDA

Now use encapsulated knowledge, not exposing the internals and also work 
with the "Tell, don't ask" principle:

$someObject->addToList($foo);

Which one do you think is better, which encapsulates its internals and 
provides real behaviour?
I know that I can add articles to a list in someObject. It doesn't 
matter how this is done by someObject. And why I should know it anyway 
how someObject works internally? And if it changes its way from list to 
hash to cache to whatever, so what?

Objects are about encapsulation, responsibility and behaviour, aren't 
they? Let them do something but also let them decide how they do it.

And the interface stays clean, even if you change the implemention of 
the article list.

Cheers,
Nino