[TYPO3-50-general] Helping Functions

[Nino Martincevic]

Hi Robert,

Robert Lemke wrote:
>>>> 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?
> 
> It allows you to change your mind and change your code so that
> it processes the value at a later time. If you use public properties
> in an API, you completely give up control.
 >
 > IMO, it is generally a bad idea to expose mutable objects / values.

+1 on this.

But please don't leave out the essential information. That way you were 
hiding the real problem the last message was depicting at.

I never talked about public properties, I talked about private 
properties and providing public getters/setters for them.
That's paradox: want to have a property private and letting it change 
from outside. These are residues of procedural programming.

(Btw: I talk about having (almost) NO properties, getters and setters! 
Trying hard to have none. Ever tried that on real responsible objects?)

So, the original problem were classes like this:

class GetterSetterMania {
  protected $foo;

  function getFoo() {
   return $this->foo;
  }

  function setFoo($foo) {
   $this->foo = $foo;
  }
}

$a = new GetterSetterMania;
$a->setFoo('boom!');

You can't say this is not the same as:

class GetterSetterMania {
  public $foo;
}

$a = new GetterSetterMania;
$a->foo('boom!');

Could you?

So, no matter if you restrict the access but provide a public access or 
declare it public from the start. It's the same.

No excuses here.
Maybe you change the getter method in near future but that's NOT an 
excuse for providing it right NOW.
Code like this is, beside the validation of essential OOP principles, 
clear YAGNI. And leads to orphaned methods later when you decide to 
provide a "real" and good interface.
So first provide that clean interface to a class with some meaningful 
behaviours and you won't have to write those getters/setters anymore.

People are so scared about continuous changes and refactoring.
Yes, your methods and interfaces may change. Yes you could break some 
old code. Yes, yes.
But if your requirements are changing that dramatically that you have to 
change some interface, well, then it changes that dramatically that you 
have to change some interfaces.
That's called change, progression and evolution.

Creating interfaces that are rock solid against ALL upcoming changes and 
can be adjusted to ANY change in future is an old dream of "technical" 
software developers (and by exposing their internals they are surely 
rock solid...).
It doesn't work in real life so why should it work in OOP?

Reusable and extendable code at first means: reusable and extendable by 
you. Without breaking too much, that's the art and the work you have to 
do constantly.

Nino