8. Inversion of Control, in software Context … publicclassCameraMan { StillCamera sCamera; public void shoot() { sCamera = new StillCamera(); sCamera.action(); } } publicclass StillCamera{ publicvoid action() { System.out.println(“ take Picture"); } } publicclassVideoCamera{ publicvoid action() { System.out.println(“video"); } }
9. Inversion of Control, in software Context … publicclassCameraMan { private Camera camera; public void shoot(){ camera = = new StillCamera(); camera.action(); } } publicinterface Camera { publicvoidaction(); } publicclass StillCamera implements Camera { @Override publicvoid action() { System.out.println(“shoot still picture"); } }
10. Inversion of Control, in software Context … publicclassCameraMan { private Camera camera; public void setCamera(Camera camera) { this.camera = camera; } public void shoot(){ camera.action(); } } publicclassMainClass { public static void main(String[] args) { Container container = new Container(); CameraMancMan =container.getComponent(“cameraman”); cMan.shoot(); } } publicclass Container { private Map<String, Object> components; public Container(){ components = newHashMap<String, Object>(); StillCamerasCamera = newStillCamera(); components.put("stillcamera", sCamera); CameraMancMan = newCameraMan(); cMan.setCamera(sCamera); components.put("cameraman", cMan); } public Object getComponent(String id){ returncomponents.get(id); } } publicinterface Camera { publicvoidaction(); } publicclass StillCamera implements Camera { @Override publicvoid action() { System.out.println(“shoot still picture"); } }
About myself and company- my aim in this presentation is to make you aware of IoC , by illustrating the design problem and learn how we can resolve the problem utilizing frameworks that implments IoC
what does it actually mean? Some of us may first end up with very puzzled. -- You go the bar and ask for the beer. You don’t tell bartender what kind of beer. So, bartender come back with bud light, coor light or heineken. -Question is what part of aspect of control are being inverted. - If your goal is to build is house, you shouldn’t be worried about how to manufacture hardware and other materials. They will be provided when needed. -- IoC works same way, A component such as DataStore can specify that it requires a DAO, and later be passed one when it is needed. If the DataStore specified that it wished to use a database-aware component, it would be totally controlling the type of object it would be using. However, by allowing the container to choose one for it, it is delegating its control. (Hence “ Inversion of Control”)-- Travelling by air you or your colleagues in an organization, need to arrange following…Decide the destination, arrival date and time.Call up airline agency for flight bookingCall up rental/cab agency for scheduling pickup/drop off --- Company decided to use another agencies, you and all other colleague has to relearn how to make contact and their mechanisms. --- New protocol: company created an administrative department, you are use IVR system where you simply state destination, dates and time, your flight reservations are made, cab is scheduled for time and ticket delivered to you. Now if preferred agencies were changed, administration dept. would become aware of a change, would perhaps readjust its workflow and IVR system could be reprogrammed but way we interact with IVR remains same. –see how dependency injection is done here!!
The biggest problem is that CameraMan class controls the creation of StillCamera object Moreover direct reference to StillCamera class leads to tight coupling between CameraMan and StillCamera
Free from object reference but still tight with control of creating StillCamera object.
This is where we completely inversion the control of creating the objects referred by the components by deligating lookup functionality and injecting dependencies to Container class- Hence, container class implemented the Inversion of control. Container is responsible for injecting the necessary resources into each component.Note as early I have stated, the component has to communicate with another component to accomplish the job in hand. A common issue to deal with is how to wire together different elements. So, at somepoint somehow somewhere, there should would be a component that creates and manages components: such components is call container. We created Container class to dump all the complexities and make other components reusable and lightweighted.
By using container framework that implements IoC, I mean that follow dependency pattern, we achieved three major advantanges.
Spring framework implements IoC principle by using Dependency Injection pattern. Here in example we are using xml-based Spring container to create, manage and inject the dependency components/objectsOnce, container take care of all contructions and managemnt of objects/component, we can focus more on implementations: The solution shifts the object creation control from CameraMan class to some one else.
The basic idea for the Dependency Injection is to have a separate component/object, an assembler, that populates a field in the CameraMan class with an appropriate implementation for the camera interface.
As stated before, IoC is the design principle and DI is the design pattern, way to implement the IoC. There are three ways of implementing IoC using DIOther way of implementations: Factory patternService locator, Sun’s core Java EE design patterns
The most popular one. container injects the dependency via setter method declared in a component.
Here dependencies are inject via a constructor. Support by most IoC container including Spring. avoids problem posed by setter injection, as all dependencies has to be provided in the constructor arguments list, so impossible to miss. once injected, can’t be modified, preventing careless modification problem. Shortcoming: JVM unable to add default constructor, explicit definition required if needed. when dependencies is high, long list of constructor arguments reduce readablity of code.
Among three types of injection, interface injection is rarely or seldom used. To apply it, component must implement a particular interface defined by the container, so that the container can inject dependencies via the interface. ShortComing: requires all the components must implement a particular interface for container to inject dependencies. Since interface is container specific, components have to rely on the container and cannot be reused outside its scope