Dependency Injection

Dependency Injection

If you search for Dependency Injection you will find out that it has been around for quite some time. It is basically a technique on software development that allow us to remove any explicit dependencies as part of an apex transaction. 
In simple words we can say that this technique allows to “feed” our code with a particular class/es “dynamically”.  I like to see it as some kind of “cross road” in which either way can be taken based on a particular logic. 

We can control the “dynamic” part with Custom Settings or Custom Metadata. This is an important piece of our puzzle because it is the one telling our code where it needs to go next.
Which “road” to take from the “cross road”… 

Scenario

We are going to take a business case and implement Dependency Injection techniques to see how we can use it with Apex. This business case is just a way to illustrate the basic principles. 

Call Center receive calls for ordering vehicles Cars and Trucks, only options available to our clients Call Center user one takes care of  car orders  Call Center user two takes care of truck orders

These “vehicles” can be set with an Engine, a GPS, and a Color! 

What we want to do here is to “supply” the “right service class” based on the user that is executing the operation. Both users can only configure the same components (engine, gps, and color) but those components need to be the specific ones for the right “vehicle”… car or truck…

So, where do we start? Interface!
Yup, we need an Interface to help us with this. 

This is the interface we are going to be using

[code lang=”php”] public interface IVehicleOrder { void engine(); void gps(); void color(); } [/code]

Using an interface is like setting up a contract. You make sure that any class instantiate the interface is going to use those methods one way or the other. To test this interface we need classes that are going to implement this interface. Here is the one for the cars

[code lang=”php”] public with sharing class CarOderService implements IVehicleOrder { public void engine() { System.debug(‘This is a Car Engine’); } public void gps() { System.debug(‘This is a GPS for a Car’); } public void color() { System.debug(‘This color is specially for Cars’); } } [/code]

We are keeping things simple here. Those methods are “mandatory”, they need to be implemented somehow. We are just getting a System.debug print from each of them

We can already test this!

Open an Execute Anonymous Window in your developer console and enter this:

[code lang=”php”] IVehicleOrder vehicleOrder = (IVehicleOrder)Type.forName(‘CarOderService’).newInstance(); vehicleOrder.engine(); [/code]

Click Execute and check your Logs

You probably can see this output:

A few interesting things took place on this operation. Type class was used to obtain a new instance of a class which was fetched by the name; Type.forName(). Is probably a good time to take a look to Apex Developer Guide subjects on this particular class to get more details on it. 

We are going to assign this class ‘CarOrderService‘ to our user one, but latter… 

Let’s take a look to the truck service class:

[code lang=”php”] public with sharing class TruckOrderService implements IVehicleOrder { public void engine() { System.debug(‘This engine is for a Truck!’); } public void gps() { System.debug(‘This GPS is for Trucks!’); } public void color() { System.debug(‘Special color for Trucks only!’); } } [/code]

As you can see it is practically the same than the one we used for the cars.

Let’s try it!

[code lang=”php”] IVehicleOrder vehicleOrder = (IVehicleOrder)Type.forName(‘TruckOrderService’).newInstance(); vehicleOrder.engine(); [/code]

After executing that on your developer console and checking your logs you should get this back:

‘This engine is for a Truck!‘

Part Two