5

I don't like having "stupid" getters and setters for every property on my entity classes so I am thinking on using magic methods to get/set those properties instead of creating every single getter and setter. The idea is to create an specific getter or setter when its logic is diffefent from the typical "return $name" or "$this->name=$name". Moreover this magic method would be created on a different class and every entity would extend it (I have not thought very much about this step)

Anyway, what do you think about replacing getters/setters with magic methods?? Would it penalize too much the performance? Any other problems that I am not taking into account?

alvaro.rmfg
  • 379
  • 3
  • 15
  • 1
    Getters and Setters allows you to control your object API. You may want a `setContainer` which accepts only a `ContainerInterface` object as a parameter, which you can hardly do with a magic setter method. Also, it allows you to add or change a behaviour of a specific getter/setter easily – Touki Aug 13 '13 at 15:21

3 Answers3

2

The problem with that is that e.g. the default template engine of symfony2 twig needs these methods. Twig translates the statement {{ object.property }} to $object->getProperty() so instead of using the very nice dot notation you would have to call properties in twig like this: {{ object.__get("property") }}.

I know that doctrine also uses magic methods in it's entity manager. So when you make a repository query for an object you can use:

 $repository->findOneByProperty($value);

instead of

$repository->findOneBy(array(
    'property' => $value
));

I would highly suggest that you do not use magic methods but instead use a get and set method for each property separately. This will also give you higher control about the state of that property.

Also be sure to checkout this Answer. It pretty much answers your question aswell.

Community
  • 1
  • 1
ferdynator
  • 6,245
  • 3
  • 27
  • 56
  • Honestly I don't know why Symfony has never just auto-defined these internally based on entity orm definitions... I mean, maybe it's nice for your code editor to automatically find the functions to suggest for you while typing or tracing, but really, I have to use a plugin to trace a lot of Symfony built-in things to begin with, so missing some "smart" behavior by default wouldn't be much different. I just consider getters and setters (especially name/case-converted) to be the caveman's way of doing ORM entities. It should be smart and intuitive out of the box, not a bunch of busywork. – SteveExdia Dec 29 '22 at 19:45
2

If you are referring to Doctrine Entity and you have nothing against code generation, you can use the doctrine:generate:entities command, eg.:

$ php app/console doctrine:generate:entities Acme/StoreBundle/Entity/Product

as explained in the documentation.

Therefore you would only need to specify the fields.

dezull
  • 990
  • 1
  • 6
  • 18
  • This is a good solution for not having to type out the getters/setters, but the underlying problem for me is having to have them to begin with. Just trying to figure out Entity classes, defined by previous developers, junked up with dozens of getters/setters and their own custom functions, many of which look ambiguous with getters/setters to begin with, has become a repetitive headache in many projects for me and others I've worked with on them. – SteveExdia Dec 29 '22 at 19:50
1

Code completion in IDE will not work in this case. Also you will be not able to make type hinting for object and arrays, and also not with the doc block. Performance will be slower but depending your project (server hardware and count of useres) you will probably don't see any differences

Lazy Ants
  • 27
  • 5
  • 8
  • I aggre with that, It is sometimes a stupid task, but you also put some more thought on your getters and settes. Sometimes you even find out that you don't need them because some properties are just not used from the outside. And most modern IDE's have a very good support for creating those methods. – m0c Aug 13 '13 at 17:51
  • also such things like refactoring in php storm will not work, because setters and getters existing only virtual – Lazy Ants Aug 14 '13 at 10:32
  • 1
    Code completion can work good with tags like `@property` in your class doc block (Major IDE supports It) – Leto Dec 16 '13 at 16:07
  • A lot of code completion and smart editor tracing/suggesting already doesn't work out of the box with editors in Symfony. The current most-popular PHP editor by JetBrains doesn't understand a lot of important pre-built Symfony standards or definitions, I have to use a plugin. Symfony not relying on hard-coded getters/setters just means a plugin would have the ability to recognize automated ones, and with a good pattern (not hard to do), that plugin wouldn't require much work to implement. Laravel's already an example of this, and it's a much more popular framework. – SteveExdia Dec 29 '22 at 19:48