The Inversion Of Control Principle
Manage All Your Toys in One Place
The Inversion Of Principle is the companion principle to the Dependency Inversion Principle.
The Dependency Inversion Principle creates an environment that supports management of the instantiation of assembly types at the highest level of module abstraction.
By having access to our dependencies at the module level that will be consuming the return response results, rather than the lower level module creating the response type, provides us with the opportunity to manage collections of dependencies in a centralized location.
The Centralized Management of our Types
puts “All of Our Toys” in one Place
The Inversion Of Control Principle States:
Software Dependency Instantiation Should be Managed at the Application Level
… Using Application Level Containers Provided By Higher Level Modules
Rather than having our lower class types “New Up“, create a required object, at the lowest module level we can use a Factory Pattern solution for managing our assembly instances in one location with greater control and performance.
A Design Pattern that Acts as an Object Instance Factory
… Is Called An Inversion Of Control Container, an IOC Container
The Major Advantages of IOC Containers:
Create a Management Solution whose Scope is at the Assembly Level
Manages Concretes from Abstractions created using the Dependency Inversion Principle
Decouples the Instantiation from the Abstractions using Concrete Resolutions
Manages Instantiation Life Cycle using Lifetime Management Strategies
Manages the Destruction of the Entities when they Required Disposal
When types are Interfaces registered within the Container then their registered Concretes can be swapped out easily through the “Resolve” process.
IOC Containers create Loosely Coupled Architectures that can Support Dynamic Changes at run time
Dynamic Run Time Changes to the Resolved Concrete Type
… Use a Run Time Process called Interception
…… To Swap out One Type for Another Based on Some Run Time Event
Business requirement change requests during the
Software Development Life Cycle (SDLC)
of the deployed application
are less expensive to implement
What is Dependency Injection?
Dependencies can be Passed or “Injected” to consuming Software Entities in Three Primary Ways:
Constructor Injection – Using the new keyword in C# to instantiate a new Type as a Parameter in a Constructor: a Class or a Method
Property or “Setter” Injection – Using the new keyword in C# to instantiate a new Type within the “setter” of a Class Level Property
Interface Injection – Passing an Abstraction to a Type that creates the Concrete Type that implements the Interface
Inversion Of Control Container facilitate the implementation of the
Dependency Injection Design Pattern
The Inversion Of Control Principle
The Inversion of Control concept is based on Dependency Inversion.
By “Bubbling Up” the lower level modules instantiated dependencies to the highest level of consumption you enable the management of those dependencies in a functionally central location.
Rather than “Newing Up” each dependency locally within a Software Entity we can use a Global Strategy know as an Instance Factory.
An Instance Factory is a code container
that manages the delivery of registered concretes
from their assigned Interface abstractions
when a Type resolution is requested
These “Inversion Of Control Containers” reside at the assembly level and available for any code block to access using a Type Resolution code pattern.
The major advantage of using an IOC Container is Global Management of assembly instantiated Types.
An IOC strategy also gives us better control of creating true Singletons.
Management of a single instance of an Object Type can be controlled from a Global perspective.
We also have better performance through repeatable strategies for Memory Management and Object Disposal processes.
There is no real “Violation” of this principle.
If the solution does not implement Dependency Inversion or Inversion of Control then the assembly cannot benefit from their use.
There are no real “Violation” symptoms of this principle, only indications that it is not being used.
If all Concretes Types are being “Newed Up” and not being “Resolved” from an Instance Factory then the Inversion of Control Principle is not in play.
The Benefits of Compliance with the Inversion Of Control Principle:
Better Memory Management of Assembly Types
Vehicle for Ensuring that Single Instances of Objects are Managed Correctly
Manages the Disposal of Objects when Destruction is Required
Encourage Coding to Abstractions Rather than Concretes
Creates the Ability to Change a Concrete Type During Run Time based on an Application Event
Dependency Inversion Creates Injectable Dependencies
IOC Containers Manage those Injected Dependencies
The Next Principle Design Series Post:
The Boy Scout Principle
… Always Leave the Environment You Visit
…… In Better Shape Than When You Entered It