[TYPO3-50-general] Helping Functions

Nino Martincevic don at zampano.com
Mon Feb 2 18:52:33 CET 2009

Hi Xavier,

Xavier Perseguers wrote:
> class person {
>     public $email;
> }
> and associated code
> $foo->email = 'somebody at domain.tld';
> echo $foo->email;

If you see me writing such a code, you are free to punish me.

> and later on when you write
> class person {
>     private $_email;
>     public setEmail($email) {
>        if (preg_match('/blabla/', $email)) $this->_email = $email;
>     }
>     public getEmail() {
>        return $this->_email;
>     }
> }

If you see me writing such a code, you are free to punish me again.

if (preg_match('/blabla/', $email)) $this->_email = $email;
is 100% violating DRY...]

> Personally, when I know that a bit later on I will validate email, I 
> would write from the beginning the getter and setter with no validation 
> code and latter on simply add the validation without having to refactor 
> anything.

In one of the responses I was talking about "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."

Rule of thumb for getters/setters, also a question for your example:
"Does Person do anything with its email or is it just there for showing up?"

Beside the fact that I would write a type-safe setter method

   public setEmail(Email $email)

(if ever) I would first think about what my class person actually stands 
for. Is it just a shape for setting and reading data or does it really 
has any importance in my model, doing other things beside that?
[ I DON'T talk about DDD here...;-) ]

Because for classes that just do reading/showing its properties I don't 
even need to write my own classes for that or at least not spend too 
much time on them. And for creation and update I use a factory that does 
the complex creation and reconstitution parts and constraint checking 
for ensuring to deliver a valid object.
By using a good ORM or just datamapper and some data checking rules e.g 
you've done this job quickly.

My Person class would have methods like (heavily depends on domain):
  sleep() -> changing STATE!
  wakeUp() -> changing STATE!
  adopt(Child $child)

This are stupid examples, I know, but you may see the intention: my 
person "lives" and does something, he lives. A person normally does not 
checks or sets it's email address or it is not one of its primarly 

The problem is the infection of minds with too data-centric systems, 
forgetting what OOP really stands for. Objects became merely data 
containers, some of them had some behaviour and state but most just had 
a bunch of properties with a bunch of getters/setters. But most of this 
properties are meaningless, primitive or read-only (just for showing) 
and can be set/unset outside the real object.
That way you have objects that really DO something and others that are 
containers for data and do only the persistence stuff or just the 
presentation stuff.
But showing attributes, just presentation, of something can also be done 
with dumb objects, queries or lists.
And you may forebode what kind of flexibility and fine-tuning 
opportunities this kind of design might have.

But nothing comes without price. For simple and data-centric systems it 
is not the preferred way, you have to write more code and gain little.
For an application where the domain objects have not much behaviour this 
would be some overkill.
Although it's never a mistake to design meaningful and "intelligent" 
objects. (Please do not confuse this with "Intelligent Design" of those 
american bastards though...)


More information about the TYPO3-project-5_0-general mailing list