The Inversion of control is a term used in Object Oriented Programming, by which the control of an object or set of objects is given to a framework or a container provided by the framework.<\/p>\n
![\"Spring](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2019\/02\/1.jpg\")
<\/figure>\n<\/div>\nAlthough, the above image intends humour, it describes what is Inversion of Control<\/em>. If we consider humans as a software component or a service, they are meant to perform the actions like wake up, go to meeting, or pay bills. For the other things like Keeping track of meetings, to set up alarms or reminders humans use Phones or any smart devices.<\/p>\n More on Spring Dependency Injection:<\/i><\/b><\/p>\n Spring Inversion of Control<\/em> is similar. We want our software components to do their given jobs. We take configurations and dependencies out of the components and give them to a container called as Inversion of Control Container<\/strong> or IOC Container. More to come in the below sections.<\/p>\n Want to learn more about Spring Framework ?<\/b><\/p>\n Read this:<\/p>\n An application is made up of multiple classes. Usually, each class should have its own dedicated responsibility.<\/em> This results in our classes integrating with different classes to get certain functionality done. When a class A calls a method of class B. Then Class A is dependent<\/strong> on Class B.<\/p>\n Learn how having a dependency can cause Tightly Coupled Objects<\/em> problem. See the below code.<\/p>\n This is a In the code above, we are using Program to Interface<\/em> principle to instantiate Let\u2019s update the Let\u2019s see what is happening in What we just did is called as Dependency Injection<\/strong>.<\/p>\n The Dependency Injection<\/strong> is a term used in Object Oriented Programming<\/em>, by which Objects will focus on doing the assigned functionality and utilising other objects. The necessary configurations and initialisations will not be handled by the objects. However, the Objects will provide a way to initialise them and their dependencies by field assignment, field setters or constructors. This way, the external entities can initialise the things and not the actual objects.<\/p>\n In a Spring based application, Inversion of Control Container<\/strong> (IoC container) does the dependency injection. We will see that in coming section. First, let\u2019s see why do we even need such a container.<\/p>\n I have modified the previous code example. It is now a To upload a resume the Below are the important issues with above<\/strong><\/p>\n This clearly indicates, we need something that can take care of all the configurations and initialisations. Something, whose sole responsibility is to manage the initialisations.<\/p>\n Spring provides an IoC Container to solve the problem. This container instantiates all the objects, and while doing so it also resolves their dependencies. The class To configure, instantiate or write beans the Application Context needs some instructions. These instructions can be provided in the form of XML configurations, Java Annotations or Code.<\/p>\n In Spring<\/strong> each object is a bean. Each object has an If we want to attach a different implementation of Everything is so clean and focused. No class is initialising another class or setting any configuration for another class. Everything is managed by Spring\u2019s Inversion of Control Container (IoC Container)<\/strong>.<\/p>\n You have come to an end of of the Spring Dependency Injection and Inversion of Control<\/strong> guide. You learnt what is Dependency<\/strong> and how classes can be Tightly Coupled<\/em> or Loosely Coupled<\/em>. We understood the concepts of Dependency Injection<\/strong> and Inversion Of Control<\/strong> in an Object Oriented Programming<\/em>. You also learnt that Spring<\/strong>\u2018s Inversion of Control Container<\/strong> (IoC Container) manages all the Dependency<\/strong> Injections in our Spring Application.<\/p>\n There are still plenty of things to learn about Springs Dependency Injection. We will cover them in sub ubsequent tutorials.<\/p>\n\n
\n
What is a Dependency ?<\/h3>\n
Tightly Coupled Objects<\/h2>\n
FileUploadService<\/code> which grabs a file, checks if the file has one of the expected extensions and asks a FileStorageService<\/code> to store the file.<\/p>\n\npublic class FileUploadService {\n \n private List<String> validFiles = Arrays.asList(\"xls\", \"doc\".\"txt\", \"ppt\");\n private FileStorageService service = new AzureBlobStorageService();\n \n public FileUploadService() {}\n \n \/\/\n \/\/ Other methods\n \/\/\n}\n<\/pre>\nFileStorageService<\/code>. But still, the respective implementation is hard-coded in the class. Also the validFiles<\/code> is hard-coded. Both of them are causing a Tightly Coupled<\/em> objects.<\/p>\nLoosely Coupled Objects<\/h2>\n
FileUploadService<\/code> a bit and we will get Loosely Coupled<\/em> objects.<\/p>\n\npublic class FileUploadService {\n \n private List<String> validFiles;\n private FileStorageService service;\n \n public FileUploadService(List<String> validFiles, FileStorageService service){\n this.validFiles = validFiles;\n this.service = service;\n }\n}\n \nclass User {\n public static void main(String[] ar) {\n List<String> validFiles = Arrays.asList(\"xls\", \"ppt\", \"doc\");\n FileStorageService service = new AzureBlobStorageService();\n \n FileUploadService fileUploadService = new FileUploadService(validFiles, service);\n }\n}\n<\/pre>\n\n
FileStorageService<\/code> type. No implementation attached.<\/li>\nUser<\/code> class, which is actually the user of FileUploadService<\/code>.\n
FileUploadService<\/code> instance is created by passing all the required arguments to constructor.<\/li>\n<\/ul>\nDependency Injection<\/h3>\n
Why do we Need an IoC Container ?<\/h3>\n
ResumeUploaderService<\/code>. A Candidate<\/code> can share its resume to the ResumeUploaderService<\/code>. The service should, upon verifying the extension, share it to a ResumeStorageService<\/code>. As per the organisations current strategy the resumes are being stored in a confidential folder of file system (by FileSystemResumeStorageService<\/code>).<\/p>\n\npublic class ResumeUploaderService {\n \n private List<String> validFiles;\n private ResumeStorageService service;\n \n public ResumeUploaderService(List<String> validFiles, ResumeStorageService service) {\n this.validFiles = validFiles;\n this.service = service;\n }\n}\n \n \nclass Candidate {\n public static void main(String[] ar) {\n List<String> validFiles = Arrays.asList(\"pdf\", \"doc\");\n \n String filePath = \"\/Users\/app\/confidential\/storage\/resume\";\n ResumeStorageService service = new FileSystemResumeStorageService(filePath);\n \n ResumeUploaderService fileUploadService = new ResumeUploaderService(validFiles, service);\n }\n}\n<\/pre>\n\n
ResumeUploaderService<\/code> has-a<\/em> reference to ResumeStorageService<\/code>.<\/li>\nResumeStorageService<\/code>.<\/li>\n<\/ul>\nCandidate<\/code> has to instantiate ResumeUploaderService<\/code> and pass resume. But with all the dependency injection<\/code> thing, Candidate\u2019s job has become difficult. Candidate will not only have to instantiate ResumeUploaderService<\/code> but also ResumeStorageService<\/code>. Because, the former cannot be instantiated without the later.<\/p>\n\n
FileSystemResumeStorageService<\/code> or AzureBlobStorageService<\/code>.<\/li>\nResumeUploaderService<\/code>.<\/li>\n<\/ul>\n\n
ResumeUploaderService<\/code> doing its job (lack of abstraction).<\/li>\nInversion of Control Container (IoC Container)<\/h3>\n
ApplicationContext<\/code> represents the Spring IOC Container. The Application context is responsible for instantiating, configuring and wiring the beans.
Remember, Beans are nothing but Java objects registered with Spring\u2019s Application Context. <\/em><\/p>\nSpring Dependency Injection<\/h3>\n
id<\/code>, or name<\/code>. An ApplicationContext<\/strong> keeps track of all such beens and ids. When a bean is requested, by a consumer, the Application Context returns an instance of the bean. Look at the below code to understand bean creation and wiring in detail.<\/p>\n![\"Spring](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2019\/02\/2.jpg\")
<\/figure>\n<\/div>\n\nimport org.springframework.beans.factory.annotation.Value;\nimport org.springframework.stereotype.Component;\n \n@Component(\"resumeStorageService\")\npublic class FileSystemResumeStorageService implements ResumeStorageService {\n \n @Value(\"${resume.storage.path}\")\n private String storagePath; \/\/ Storage path assigned based on properties file\n \n \/\/\n \/\/ Skipped methods\n \/\/\n}\n<\/pre>\n\n
\nimport org.springframework.beans.factory.annotation.Autowired;\nimport org.springframework.beans.factory.annotation.Qualifier;\nimport org.springframework.stereotype.Component;\n \n@Component\npublic class ResumeUploaderService {\n \n @Autowired\n @Qualifier(\"resumeStorageService\")\n private ResumeStorageService storageService;\n \n \n public ResumeUploaderService(ResumeStorageService storageService) {\n this.storageService = storageService;\n }\n \n \/\/\n \/\/ Skipped methods\n \/\/\n}\n<\/pre>\n\n
ResumeStorageService<\/code> implementation which is identified by \"resumeStorageService\"<\/code>.<\/li>\n<\/ul>\nResumeStorageService<\/code> the ResumeUploaderService<\/code> is not going to change at all.<\/p>\n\nimport org.springframework.beans.factory.annotation.Autowired;\n \npublic class Candidate {\n @Autowired private ResumeUploaderService resumeUploaderService;\n \n public void upload(Byte[] resume) {\n resumeUploaderService.uploadResume(resume);\n }\n}\n<\/pre>\n\n
resumeUploaderService<\/code>.<\/li>\n<\/ul>\nSummary<\/h3>\n