[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.
[And
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):
eat($stuff)
drink($vodka)
sleep() -> changing STATE!
wakeUp() -> changing STATE!
adopt(Child $child)
dressUpWith($clothes)
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
responsibilities...
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...)
Cheers,
Nino
More information about the TYPO3-project-5_0-general
mailing list