Getting a set of dependencies to a class deeply nested in the dependency graph

Question

So here is my problem:

For instance, consider that:

A File has a set of Classes, as well as Imports.

A Class has a set of Instance Methods, Static Methods and Variables.

A Instance Method has Parameters and a Body.

The Body has ... yadayada.

The problem, when modelling this in a OO way is that Body may need a lot of specific dependencies to function:

class Body {
    ...

    public Body(Dependency1, Dependency2, Dependency_n, ...) { }

    ...
}

that all the other classes won't need, to run. The question I'm putting here is on how to get those dependencies to Body without having to pass all this dependencies through File, Class and InstanceMethod.

I could create a BodyFactory, but the problem would still be the same, as I'd have to pass the BodyFactory through File, Class and InstanceMethod, if I'm not missing anything.

How to solve this issue without resorting to singletons?

score 4 · Accepted Answer · answered Feb 15 '12 at 14:56

4

Let Body implement an IBody interface and let InstanceMethod depend only on IBody and IEnumerable<IParameter> (if we assume C# - in Java it would be a differently named collection interface, but the principle would be the same).

Repeat this process of refactoring to Facade Services all the way to the Composition Root, where you can then compose the entire object graph like this:

File file = new File(
    new List<IClass>
    {
        new Class(
             new List<IInstanceMethod>
             {
                 new InstanceMethod(
                     new List<IParameter>(),
                     new Body(
                         new Dependency1()
                         new Dependency2(),
                         new DependencyN()))
             },
             new List<IStaticMethod>(),
             new List<IVariable>())
    },
    new List<IImport>());

answered Feb 15 '12 at 14:56

Mark Seemann

225,310
48
427
736

The trouble is that I actually want to have all the instance generation logic to be inside Instance Method. From what it seems from your suggestion, one would want to pass the instantiation logic to the composition root. Am I right? – devoured elysium Feb 15 '12 at 15:10
The trouble with "Compose object graphs with confidence" is that the number of objects that will be created at run-time is unknown. – devoured elysium Feb 15 '12 at 15:12
I do get what you mean, but I cannot think of a way of doing what you're saying when there are an arbitrary number of File instances, Class instances, Instace Methods instances and Body instances. At least not without putting all the Body instance creation logic currently found on InstanceMethod outside of all this dependency graph. – devoured elysium Feb 15 '12 at 15:17
If there are unknown numbers of instances it sounds like you looking towards composing Entities or Value objects, and not Services. http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec/4836790#4836790 – Mark Seemann Feb 15 '12 at 15:20
I'm going to read the paper. Anyway, I think what I want to do here is to separate the logic and data (in a kind of functional style - or better yet, how one does with compiler's symbols table). – devoured elysium Feb 15 '12 at 15:24

score 0 · Answer 2 · answered Feb 15 '12 at 14:50

0

It seems that you are dreaming about kind of injection framework. For example Spring Framework.

answered Feb 15 '12 at 14:50

AlexR

114,158
16
130
208

score 0 · Answer 3 · answered Feb 15 '12 at 14:52

As far as Java is concerned, I don't think you have a workaround here, if a method takes n parameters, then you are going to have to pass them, so you are going to have to carry them all the way, a solution to make this more elegant is to create a DataWrapper, call it BodyBean and pass it also all the way down.

Then you have the other option don't use parameters, then if these guys are singletons, just inject them, which by the way is the option I would recommend you

Getting a set of dependencies to a class deeply nested in the dependency graph

3 Answers3

Linked