The abuse of object factories

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

Once upon a time… in Objectsland

where only objects with a meaning are admitted

"Spiral Jetty" by Robert Smithson
“Spiral Jetty” by Robert Smithson

Once upon a time, there was a place called Objectsland.
Every day, objects were living their life, working together, forming new collaborations.
The city was continuosly growing and flurishing.

One day, Necromancer Techcoacho Ignoranto arrived in the city.
He had to deal with all the objects in the city.
Soon, he became scared. He didn’t want to deal with so intelligent objects.
He’d have want objects without a brain, so that he could control them.
The other objects would have not left him doing that, so, one night, he decided to cast a spell mentioned in ancient books of refactoring: “Parameter Objectorum!!!”

The day after, Objectsland seemed as before, but after few weeks new objects arrived… they were like buckets of texts, numbers, … and they were a lot… they were: the Parameter Objects! uhuhohohahahahahahah

One day, one of this Parameter Object was filled with a text girl called Airline and a boy called Flightnumber.
Airline was in love with Flightnumber, but she was just a lonely text and he was just… a number (e.g. 89)? or a text (e.g. “0089”)? he didn’t know…

Since the arrive of all those Parameter Objects, the life in Objectsland became difficult. You had to deal always with them for everything and they were so many that you didn’t know who was in charge of something.

One day, a mage arrived in Objectsland. He was called Oldoop Pragmatico.
Looking at the poor Airline walking alone far from Flightnumber, he decided to step in! Immediately, he cast the powerful spell: “Ubique Dominatum!!!”

Since then, no one has seen a Parameter Object.
Eventually, Airline married Flightnumber and they decided to form a family: they called themself FlightDesignator following the suggestion of IATA Guild.

All the free objects decided to put a signboard at the entrance of the city.
This is the message:

Welcome to Objectslands where only objects with a meaning are admitted.
For data buckets, DTOs, etc… please follow the other street.
It will lead you to Wasteland

A note for Software Engineers:
yes, I’m arguing that ParameterObject is an antipattern that will get you to MagicContainer sooner or later.
It’s just a matter of time.