The document discusses the basic concept of Inversion of Control (IOC) and how to implement it using the Spring Framework. It explains that Spring is lightweight, non-intrusive, and uses IOC to achieve loose coupling between application components. It then covers factory patterns, dependency injection, and how to configure the Spring container to manage beans and their dependencies. Code examples are provided to demonstrate implementing IOC without and with Spring to reduce tightly coupled relationships between classes.

1. The Basic Concept Of IOC
(Implement with Spring Framework)
Kevin Lu
yotsuba1022@gmail.com

2. Agenda
• Why Spring Framework?
• Inversion of Control
• Factory Pattern
• Spring Container, Configuration and DI
• DIY
• Conclusion

3. Why Spring Framework?
• It’s a lightweight framework:
The core of Spring is less than 1MB.
• Non-Intrusive:
You can use SpringFramework without any implementation or
extension. This can let you feel less the existence of Spring and
significantly reduce the burden when transplant your applications.
• Inversion of Control(IOC):
We know it’s important to achieve decoupling when building an
application, and IOC will help you to reach this goal easily.

4. Inversion of Control
What’s IOC?
In this picture, it’s intuitive that all objects
controlled by the dependency injector is more better
than the complex relationship in traditional situation.

5. Inversion of Control
• What’s Dependency?
When a class extend, implement another class, or maybe call some
other classes, we call this class depends on another class.
Ex:
public class Cat implements Animal{
public String makeSound(String sound){
return sound;
}
}

6. Inversion of Control
• It’s important to reduce the dependency between each components,
when the dependency is too high, it may reduce the reusability of
your applications. So, for the sake of high reusability, we should
strive to reduce the dependency between each components.

7. Factory Pattern
• In design pattern, the factory pattern can separate the code of
creating instances and let other parts which need to use the same
code to reuse those separated code.

8. Factory Pattern
• If you want to develop a logger, you may design as below at the
first time.

9. Factory Pattern
• Build the object you need:
public class AService{
private final Logger logger = new ConsoleLogger();
//Other code…
}
• If you need to use more logger, you must modify your program:
public class AService{
private final Logger consoleLogger = new ConsoleLogger();
private final Logger fileLogger = new FileLogger();
//Other code…
}

10. Factory Pattern
• To solve this problem, we can use factory pattern to handle it.

11. Factory Pattern
• Delegate the factory to achieve the job of creating objects.
public class LoggerFactory{
public static Logger createLogger(String kind){
if(“File”.equals(kind)){
return new FileLogger();
}
if(“Console”.equals(kind)){
return new CinsoleLogger();
}
}
return null;
}

12. Factory Pattern
• So, all objects you need will be created by the factory…
public class AService{
private final Logger consoleLogger =
LoggerFactory.createLogger(“Console”);
}

13. Spring Container
• The container gets its instructions on what objects to instantiate,
configure, and assemble by reading configuration metadata.
• The configuration metadata is represented in XML, Java
annotations, or Java code.

14. Configuration Metadata
• XML-based configuration metadata shows these beans configured as
<bean /> elements inside a top-level <beans /> element.
Ex:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<bean id="..." class="...">
<!-- collaborators and configuration for this bean go here -->
</bean>
<bean id="..." class="...">
<!-- collaborators and configuration for this bean go here -->
</bean>
<!-- more bean definitions go here -->
</beans>

15. Instantiating a container
• The location path or paths supplied to
an ApplicationContext constructor are actually resource strings that
allow the container to load configuration metadata from a variety of
external resources such as the local file system, from the
Java CLASSPATH.
• You can use the application context constructor to load bean
definitions from all these XML fragments.
Ex:
ApplicationContext context = new ClassPathXmlApplicationContext(new
String[] {"services.xml", "daos.xml"});

16. Instantiating a container
• Alternatively, use one or more occurrences of
the <import/> element to load bean definitions from another file
or files.
Ex :
<beans>
<import resource="services.xml"/>
<import resource="resources/messageSource.xml"/>
<import resource="/resources/themeSource.xml"/>
<bean id="bean1" class="..."/>
<bean id="bean2" class="..."/>
</beans>

17. Naming Bean
• Use the id and/or name attributes to specify the bean identifier(s).
• You can also specify them in the name attribute, separated by a
comma (,), semicolon (;), or white space. As a historical note
• You are not required to supply a name or id for a bean.
Ex :
<bean class="examples.ExampleBean"/>
<bean id="exampleBean1" class="examples.ExampleBean"/>
<bean name="exampleBean2" class="examples.ExampleBean"/>
<bean name="exampleBean3,exampleBean4"
class="examples.ExampleBean"/>

18. Using the container
• Using the method getBean(String name) you can retrieve instances
of your beans
Ex:
//create and configure beans
ApplicationContext context = new
ClassPathXmlApplicationContext(new String[] {"services.xml",
"daos.xml"});
//retrieve configured instance
PetStoreServiceImpl service = context.getBean("petStore");

19. Dependency Injection
DI(Dependency Injection) exists in two major variants
• Constructor-based dependency injection
• Setter-based dependency injection

20. DIY
• Now, it’s time to write some code, before start, you’ll need the
following things:
o STS(Spring Tool Suite)
o JAVA(SE1.6)
o Maven(Not necessary)

21. Build your project
• In STS, build your own project. Here I build a Maven
project because I want to use pom.xml to include JUnit4.0
and spring-context, if you don’t like maven, just choose the
way you like.

22. Build Employee
• First, create an interface, here I named it “Employee”.

23. Build Employee
• With an interface, we should implement it, so create a class
named “ProjectManager”(Maybe you like other career, it’s up
to you).

24. Build Item
• And each employee has their own computer, maybe PC or
Notebook. With this situation, we can create an interface
named “Computer”.

25. Build Item
• Let’s implement the interface “Computer”. First, we create a
class “PersonalComputer”.

26. Build Item
• And then the class “NoteBook”.

27. Ready To Go
• Now, we’ve create all the employee and items we need. So
it’s time to simulate the following situations:
o Before IOC.
o After IOC.
o Using Spring.

28. Before IOC
• Before we realize the concept of IOC, we may coding as
below:
You can see that there are keywords “new” here. In fact,
“new” here will generate dependency between class “IdiotIT”,
“PersonalComputer”, and “ProjectManager”.

29. Before IOC
• Running “IdiotIT”, the result may like following:

30. Before IOC
• If using UML, it may like this: It’s clearly that there are
dependencies between these classes, and it’s not a well-
design program.

31. After IOC
• So, how can I reduce, or eliminate the dependency between
these classes? Remember? We’ve told “Factory Pattern”
before. So let’s build our factory to generate computers…

32. After IOC
• Using factory to generate our computers…

33. After IOC
• See? The result is very normal too. But we eliminate the
dependency between “IdiotIT2” and “PersonalComputer”.

34. After IOC
• In UML, it will like this: It means that you can change the
code of “PersonalComputer” without any modification about
“IdiotIT2”.Because “IdiotIT2” only depends on
“ComputerFactory”

35. After IOC
But, there are still some problems…

36. After IOC
• Let’s back to the “ComputerFactory” we’ve built. Here we can
know that if we need to add more type of computers, we’ll
write more “if” block in this class…

37. After IOC
• OK, just like this. This is not a well-design program because
it repeat the “if” block too many times.
.
.
.
.
.

38. After IOC
So, we need some mechanism that can
help us to reduce those repeat blocks…

39. After IOC(Phase-II)
• It’s time to use reflection mechanism…, here we can create a
new factory that using reflection. With reflection, our
factory can be enhanced so that there will not appear any
repeated “if” block.

40. After IOC(Phase-II)
• With enhanced factory, now we can see that there are no
dependencies between IdiotIT2, ProjectManager and
PersonalComputer. The only one dependency here is between
IdiotIT and our factory.

41. After IOC(Phase-II)
• Now, run our new version of IdiotIT2 to see the result.

42. After IOC(Phase-II)
• The result looks like very normal. And here we can notice
that although we generated two personal computers, the
factory still use the first one it generated.

43. Using Spring
The above we were talking about was what Spring
done for us behind your code, now let’s take a look
to see how to use Spring to reach IOC in our
application.

44. Using Spring
• Now you’ve known what’s IOC, so let’s using Spring to help us
to do all of these things. If you want to use maven, you can
add the following dependencies in your pom.xml.

45. Using Spring
• Create a configuration file, here I named it “Spring-
configuration.xml”, well, it’s up to you.

46. Using Spring
• With this xml configuration file, we can tell Spring which
bean needs to be managed. And set some properties to the
specified bean.

47. Using Spring
• Now, create a class to test. Here you can use
“ClassPathXmlApplicationContext” to load the configuration
we defined before.

48. Using Spring
• And when we need to call the beans defined in configuration
file, we should call the ApplicationContext object first, then
using “getBean” method with the bean id.

49. Using Spring
• Hmm, it works well.

50. Conclusion
We’ve discussed the basic concept of IOC, and implemented it
with Spring Framework, I hope that it could make you more
realize about why we need to follow this mechanism and how
does it work. Wish you have a more comfortable develop
experience with IOC.

51. Thank you for your attention!