If you search for Dependency Injection<\/em> 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. We are going to take a business case and implement Dependency Injection <\/em>techniques to see how we can use it with Apex. This business case is just a way to illustrate the basic principles. <\/p>\n These “vehicles” can be set with an Engine<\/strong>, a GPS<\/strong>, and a Color<\/strong>! <\/p>\n 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…<\/p>\n So, where do we start? Interface! This is the interface we are going to be using<\/p>\n[code lang=”php”]\npublic interface IVehicleOrder {\n void engine();\n void gps();\n void color();\n}\n[\/code]\n 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<\/p>\n[code lang=”php”]\npublic with sharing class CarOderService implements IVehicleOrder {\n public void engine() {\n System.debug(‘This is a Car Engine’);\n }\n\n public void gps() {\n System.debug(‘This is a GPS for a Car’);\n }\n\n public void color() {\n System.debug(‘This color is specially for Cars’);\n }\n\n}\n[\/code]\n 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<\/p>\n We can already test this!<\/p>\n Open an Execute Anonymous Window<\/em> in your developer console and enter this:<\/p>\n[code lang=”php”] \nIVehicleOrder vehicleOrder = (IVehicleOrder)Type.forName(‘CarOderService’).newInstance();\nvehicleOrder.engine();\n[\/code]\n Click Execute<\/em> and check your Logs<\/p>\n You probably can see this output:<\/p>\n A few interesting things took place on this operation. Type<\/strong> class was used to obtain a new instance<\/em> of a class which was fetched by the name; Type.forName()<\/em>. Is probably a good time to take a look to Apex Developer Guide subjects on this particular class to get more details on it. <\/p>\n We are going to assign this class ‘CarOrderService<\/em>‘ to our user<\/strong> one, but latter… As you can see it is practically the same than the one we used for the cars. After executing that on your developer console and checking your logs you should get this back:<\/p>\n
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<\/em> or Custom Metadata<\/em>. 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<\/strong><\/p>\n\n\n
\n \n \n
Yup, we need an Interface to help us with this. <\/p>\n![\"\"](\"http:\/\/ccloudonline.nl\/wp-content\/uploads\/2020\/01\/Screen-Shot-2020-01-11-at-5.56.35-PM.png\")
<\/p>\n
Let’s take a look to the truck service class:<\/p>\n[code lang=”php”]\npublic with sharing class TruckOrderService implements IVehicleOrder {\n public void engine() {\n System.debug(‘This engine is for a Truck!’);\n }\n\n public void gps() {\n System.debug(‘This GPS is for Trucks!’);\n }\n\n public void color() {\n System.debug(‘Special color for Trucks only!’);\n }\n\n}\n[\/code]\n
Let’s try it!<\/p>\n[code lang=”php”] IVehicleOrder vehicleOrder = (IVehicleOrder)Type.forName(‘TruckOrderService’).newInstance(); vehicleOrder.engine(); [\/code]\n