Recently I found this smell: the abuse of object factories.
Usually, there is already another smell: you are using DTOs.
Do not try to fake it removing “DTO” from the name. Instead, please read “Let the domain drive” architectural pattern and save yourself from a life of dumb conversions
You need to create it with some domain objects involved.
And… now… you have an object factory.
I rarely use object factories, because usually the constructors or a factory method are enough.
I use these rules:
- if I am creating an object at the edge of the hexagonal architecture and I realise that I need to create it just “manipulating data” from other domain objects (and again… lots of smells here), a factory method or a constructor should be enough.
Then, if a test gives me the feedback that I cannot proceed with that solution(*), I’ll move to an Abstract Factory design pattern (or a more simple object factory) - if I am creating an object at the same level(**) of others needed to create it, sometimes I use the previous rule, while sometimes I ask to one of those objects to transform itself in the one I need (such as Java does with that
toString)
I know that this is a basic/simple topic, but it can reduce significantly the number of objects in your application. Recently, applying this “tecnique”, we reduced the number of objects in a package from 13 to 8. Not a big improvement, but the code is definitely more simple to read and change.
(*) for example, due to the number of collaborators involved, etc…
(**) “same level” means that you have all domain objects or all objects at the edge of the hex arch
