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

Comments

Post a Comment

Popular posts from this blog

First Experience, Then Words

-
I read several books in 2025. I dedicated months to them. I processed them, assimilated them. I collected interesting notes in my Zettelkasten . I made connections. The information is there, and I have it in my head (well, not everything :) but still easily accessible).   But something is missing.   It still feels like wallpaper in a house that doesn’t feel like mine, or more like tissue paper. I became a manager a year ago, but I haven’t been able to apply that knowledge yet. The situations in which I could apply what I’ve learned aren’t as frequent as when I was a programmer (oh, even then, sometimes you had to wait for the right moment or project). As a manager, time is much more stretched. To apply some things, a specific “setup” within the organization or politically complex situations is required, which I don’t have in my current company (and maybe, for some situations, I’m even lucky not to have to face them). How do I write about something that doesn’t feel l...
Continua a leggere...

Management and power

-
A manager must acquire knowledge in several areas: communication team management strategy planning performance appraisal This is why a manager must necessarily embrace a multidisciplinary approach. Unfortunately, there is one area that few want to talk about but is quite important: managing interpersonal relationships Most of the books I've read only briefly touch on this aspect because delving into it would lead them to, for example, two activities that inherently carry a negative connotation: understanding power dynamics managing one's influence Books that want to make aggressive marketing or are not hiding reality from the reader explain with one word what these activities refer to and do not use the term "managing interpersonal relationships," but rather a much clearer and direct one: power. Power is one of the aspects that a manager must understand. What are its dynamics within the company? Can we influence it? How? By managing interpersonal relationships? Maybe ...
Continua a leggere...