Object Creation - Whose Responsibility
-
I have a class A whose instances contain a few class B's, and a few class C's. The objects are all constructed from database records, one record representing a single A, B or C. The objects are read from the database and created at application startup. The problem is that I can't decide between different instance creation strategies. -- Should I call a single method of class A, and have A construct all of its contained B's and C's? -- Should I have a separate factory class construct all three classes and set which objects are contained by which other objects? -- Or maybe a factory class that constructs A, and in turn A constructs its B's and C's? Which pattern is most preferred? Perhaps one I haven't mentioned?
The difficult we do right away... ...the impossible takes slightly longer.
-
I have a class A whose instances contain a few class B's, and a few class C's. The objects are all constructed from database records, one record representing a single A, B or C. The objects are read from the database and created at application startup. The problem is that I can't decide between different instance creation strategies. -- Should I call a single method of class A, and have A construct all of its contained B's and C's? -- Should I have a separate factory class construct all three classes and set which objects are contained by which other objects? -- Or maybe a factory class that constructs A, and in turn A constructs its B's and C's? Which pattern is most preferred? Perhaps one I haven't mentioned?
The difficult we do right away... ...the impossible takes slightly longer.
I tend towards "builder" classes: static classes with static methods that construct these "object graphs" (that reside in memory / data class / repository). And may also serialize and deserialize them. They often run async. Sometimes I build top down; sometimes bottom up (summing). "Adapters" let me step "outside the box" instead of thinking "how can I build 'myself'". I sort of patterned it after the .NET table adapter and the concept of the "fill" method (which in that case fills tables and data sets). (So: "option 2")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I tend towards "builder" classes: static classes with static methods that construct these "object graphs" (that reside in memory / data class / repository). And may also serialize and deserialize them. They often run async. Sometimes I build top down; sometimes bottom up (summing). "Adapters" let me step "outside the box" instead of thinking "how can I build 'myself'". I sort of patterned it after the .NET table adapter and the concept of the "fill" method (which in that case fills tables and data sets). (So: "option 2")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Thanks for the reply, Gerry. What's the theory behind your preference? Is there one, or do you just like to do it that way?
The difficult we do right away... ...the impossible takes slightly longer.
-
Thanks for the reply, Gerry. What's the theory behind your preference? Is there one, or do you just like to do it that way?
The difficult we do right away... ...the impossible takes slightly longer.
Some of the object graphs I build contain thousands of entries; and 4 levels deep. I'm wiring up a hierarchy. There is no container; the hierarchy is an illusion; what "level" should build the tree? An "adapter" builds the tree (a recursive structure of entities imported from a csv type text file; then serialized to binary).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I have a class A whose instances contain a few class B's, and a few class C's. The objects are all constructed from database records, one record representing a single A, B or C. The objects are read from the database and created at application startup. The problem is that I can't decide between different instance creation strategies. -- Should I call a single method of class A, and have A construct all of its contained B's and C's? -- Should I have a separate factory class construct all three classes and set which objects are contained by which other objects? -- Or maybe a factory class that constructs A, and in turn A constructs its B's and C's? Which pattern is most preferred? Perhaps one I haven't mentioned?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
few class B's, and a few class C's...Which pattern is most preferred?
Unless there is more information than what you posted then you are spending time on something that is not worth spending time on. Any way that you do it is going to be sufficient.
-
Thanks for the reply, Gerry. What's the theory behind your preference? Is there one, or do you just like to do it that way?
The difficult we do right away... ...the impossible takes slightly longer.
I agree here; the static factory has the advantage that you can easily track and modify the way an object is created. Instead of modifying a lot of new This() and new That(A, B) statements, you have a BuildA(). And you can modify the behavior's of all BuildA's at a single point. To make a short story longer, a practical example is adding a logger in a factory; A short tale on two patterns that live in .NET[^] :rolleyes:
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Richard Andrew x64 wrote:
few class B's, and a few class C's...Which pattern is most preferred?
Unless there is more information than what you posted then you are spending time on something that is not worth spending time on. Any way that you do it is going to be sufficient.
jschell wrote:
you are spending time on something that is not worth spending time on
I understand this point. One solution I told myself was to pick the way that I think I can do it with the fewest difficulties. I thought I would post the question because it is one that I have quite often, and I'm wondering if there's a best practice. So the question is not really a waste of time.
The difficult we do right away... ...the impossible takes slightly longer.
-
I tend towards "builder" classes: static classes with static methods that construct these "object graphs" (that reside in memory / data class / repository). And may also serialize and deserialize them. They often run async. Sometimes I build top down; sometimes bottom up (summing). "Adapters" let me step "outside the box" instead of thinking "how can I build 'myself'". I sort of patterned it after the .NET table adapter and the concept of the "fill" method (which in that case fills tables and data sets). (So: "option 2")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
beauty center in Iran with baroro https://baroro.ir
