I am concerned about whether or not I am using
I am refactoring legacy code and I have identified a pattern: there is a
God Object that is created in memory, and later various parts of it is saved to many different tables. For example, various parts are called
What I've done
I created a
SelectionPersisterFactory that returns a
SelectionPersister object, which is responsible for saving
Selection to database.
Next step would be to create
DesignPersisterFactory that returns
DesignPersister, which saves
Design to database.
But then I stopped myself and ask:
Can I create a single
PersisterFactory and have that return
PlotPersister, etc? from one single factory?
"The Pro" will be that all of them are using the same repository and I can initialize that repository one time, instead of doing it for every new type of
"The Con" is that I will be tasking the factory with creating different types of Persisters, but I am not sure if it's a necessarily a bad thing. i.e. I am not sure whether or not I'll be breaking SRP.
To clarify my title, "similar purpose" - objects are meant to persist something, "different in focus" - the persister objects focus on different parts of
Goal / Use Case
Current situation is that I have the god object containing everything generated during "customer activity". That object is an in-memory object. It also permeates a lot of the codebase and is impractical to change on a moment's notice. It is not always nicely separated into its own distinct sub-components, although it tries.
The task at hand is "Save this session of customer activity (aka the god object) into the database". That includes saving:
- User-Selected Items to table
- Plot generated from above items into table
- Design object data from above items, into table
- and so on (just 1-2 more)
Why you think you need all these different persisters?
Different parts draw from different sections of the god object. Originally it was all procedural code just doing SQL statements doing all of the above DB saving, spanning 500+ some lines. I wanted to break it up into more manageable pieces, and came up with an idea "Let's separate saving different parts of god-object into separate methods". Since they are being persisted into the database, why not call them
it would be worth to know if you have only a small fixed number of parts class
Yes I have a fixed number of parts classes, say 5 or 6. Different "customer activity" generates slightly different needs. So some sessions may have the need to persist 1 or 2 parts, some might need all 5. I do not anticipate the need to add more part classes, but rather aim to keep code simple.