Summary
There are many examples in enterprise software where performing a function requires invoking a chain of objects in an invocation pipeline. In an IBM developerWorks article, André Fachat shows how inversion of control can simplify the design and implementation of such invocation chains.
Advertisement
Inversion of Control, or IoC, is frequently associated with configuring app servers or, more generally, containers: Instead of a container having to find its configuration, dependencies are injected into the container and all the container has to do is invoke methods on the injected objects to function as desired.
A recent IBM developerWorks article by André Fachat, Use Inversion of Control in Method Signatures, focuses on how that same principle can be used in an another common enterprise pattern that centers around invocation pipelines.
Such pipelines arise when performing a business function—placing an order, for instance—requires the invocation of many objects in succession:
Assume that Component1 needs to call method2 and method3 with the same input data to get different output data. For example, Component1 could be an order-preparation component, method2 a method to determine lead times, and method3 a method to determine prices. Both methods need the same input and provide different output.
In this case, using value objects as method parameters requires that Component1 create the value objects for each method call and actively copy the values required into the value objects. Also, each of the value objects must be instantiated...
More information about the pipeline pattern is available from an entry on PipelineProcessing in a parallel patterns article repository at the University of Florida.
Creating many value objects for the sole purpose of passing them around to other objects in the invocation chain is an overhead that can be avoided by using interfaces in place of objects, according to Fachat:
You can ... use IoC on the method signatures to decouple the methods from the value objects. You do this by replacing the value objects in the method signatures with interfaces...
Using interfaces as method parameters is ... in IoC terms ... a form of context IoC, applied on a dependency of the caller. Just as a dependency component (such as >PriceComponent) is injected into a caller component (such as OrderPrepareComponent), the caller component injects its dependency object (the implementation of the method parameter interface) into the dependency component's method.
Fachat believes that this approach provides a similar degree of simplification, and possible performance improvement, for invocation pipelines as it does for containers:
This approach simplifies the implementation of the pipeline pattern, where data is piped from one component to the next, and where one stage of the pipeline (component) uses data provided by previous steps in the pipeline.
What do you think of Fachat's use of IoC for invocation piplines?
I must be missing something. The article is ostensibly about IOC but it seems really to be more of a lesson about using interfaces.
I read it over a few times trying to find the dependency injection. Finally I noticed this in the intro:
"This article shows you that you can also use IoC on the method signatures to decouple the methods from the value objects. You do this by replacing the value objects in the method signatures with interfaces."
This constitutes IoC? Or rather, changing your parameters to interfaces from Value Objects makes it IoC?
Then there is the non-sequitur:
"In this case, using value objects as method parameters requires that Component1 create the value objects for each method call and actively copy the values required into the value objects..."
That's only true if the parameters require two unrelated types. Given the code examples (no example is given for the value-object version), this doesn't seem to be a given.
I mean don't get me wrong, interfaces are great but where's the discussion about IoC? The only IoC I see in this is that Componet1 and Component2 are retrieved from other Objects that could possibly have been supplied through dependency injection but that's never really stated it could be implied by the statement: "In Figure 1, Component1 depends on Component2 and Component3 (in terms of IoC)." But this is clearly not the subject of the discussion. Using interfaces is the point.
"...The following sections show how you can optimize performance instead."
Wait, now it's about optimizing performance?
In the end, the point is that if you are using the data pipeline pattern, with methods that don't use common types as parameters, using interfaces makes it easier. What does that have to do with IoC?
Beyond that, the whole things is very muddled. For one thing, in the pictures, it's method2 and method3 and out of nowhere in the example section, it's talking about method1 and method2. I don't want to nitpick but why even use names like method2 and method3? Would it have been harder to use the 'real-life' example the whole way through? It would make things a lot clearer.
I have no idea what this is supposed to mean:
"You might wonder about the OrderDB component in Figure 3 and its readCart() method. Indeed, this is a special case. In the preceding example, all objects that were modified by the dependency method (such as getPrices(...)) were already passed as method parameters. This is impossible when the component is reading data from a database because in this case, the number of items in the shopping cart is unknown before it's read."
What is impossible exactly?
Finally, isn't this whole approach a bit procedural? I mean, passing objects full of data to methods that do stuff to them is a prodcedural approach, is it not?
"I mean don't get me wrong, interfaces are great but where's the discussion about IoC? The only IoC I see in this is that Componet1 and Component2 are retrieved from other Objects that could possibly have been supplied through dependency injection"
It should be:
"I mean don't get me wrong, interfaces are great but where's the discussion about IoC? The only IoC I see in this is that Componet1 and Component2 could possibly have been supplied through dependency injection"
> I must be missing something. The article is ostensibly > about IOC but it seems really to be more of a lesson about > using interfaces. > > I read it over a few times trying to find the dependency > injection. Finally I noticed this in the intro: > > "This article shows you that you can also use IoC on the > method signatures to decouple the methods from the value > objects. You do this by replacing the value objects in the > method signatures with interfaces." > > This constitutes IoC? Or rather, changing your parameters > to interfaces from Value Objects makes it IoC? >
Yes, I noticed on second reading that the article used some loose terminology, and would definitely have needed editing. I think his main point, beyond using interfaces, was that the implementation of those interfaces can be viewed as a way to 'configure' the objects those implementations are passed into, sort of like IoC does with, say, containers.
Previous Topic
