1.HelloWorld and modularization
In the development of the team, we have such a [Enter] information needs: to achieve some output function, the function [A] Enter a HelloWorld (here represented by the function A, of course, function A can also be more complex functions).
But certainly more than a single function A in a system applications often have other functions B, C ... features a series of functions, these different functions make up a complete business system.
For example, in HelloWorld program, we not only want to output HelloWorld, we also want to export HelloJava, HelloSpring and other information.
In this single program, we use this centralized development model is no problem. But in the development of the team, a complex system in this way would be a very bad thing (not flexible, coupling a serious, collaborative development of low efficiency and so on).
This time it should reposition itself artifact Java package (package is an object-oriented language common characteristics), to encapsulate HelloWorld upgrade. (The function A, the function B, function C, etc. packaged into a separate module)
In this way you and your colleagues will be a division of labor by your completion A'HelloWorld ', by the completion B'HelloJava your colleagues'. And after modular, if a single function changes will not modify the main program, you can just modify the corresponding function module.
Our main Hello became the assembly division, write code that can streamline production (assembly line efficiency MAX, do yard farmers that way it?).
Now that we know the package, then the above procedure may wish to transform it.
Of course, such a transformation is because the function A, function B to do the same, we had a package. If modularity is packaged for different functions (concealment and increase the independence of the code), and this is a package (to improve the reusability of code) for a similar function.
Summary: Social Development, business changes, and demand will change, programmers must learn a series of thought: encapsulation, modular assembly line respond to the needs always bound to change, enhance the robustness and scalability of the code.
2. The relationship between class and class
万物皆对象，在Java中类是对 对象的描述（定义），类中的属性和方法就是对 对象的状态和行为的描述。
一个Java系统应用是由许多类组成的，那么这些类之间有什么样的关系呢？
类与类之间大体上有三种关系：
- 继承关系（泛化）针对类或接口的子类的extends,针对抽象类或接口的实现类的implements。
- 关联关系（依赖）依赖分为弱依赖（在方法/行为中发生依赖）和强依赖（在属性/状态中发生依赖），在依赖关系中我们更多的关注强依赖关系：包括聚合（has a,）和组合(contains a)两种形式（两者简单的区别是:聚合的依赖可以独立存在，而组合的依赖不能独立存在）。在开发中我们更多的使用聚合关系，例如JavaBean。
- 独立关系（无关）两个类之间不发生交互。
更详细的资料可以查阅UML（统一建模语言）的相关知识，其中会对类图以及类关系作详细描述，也可参考《UML精粹》等书籍，这些对面向对象设计（OOD）很有帮助。
我们在面向对象编程（OOP）中关注的问题是，如何处理类与类之间复杂的依赖关系。
3.控制反转和依赖注入
在学习控制反转和依赖注入的过程中Martin Fowler的文章是必读的，描述的非常详细。这里是学习后的一个总结。
- 对比模块化中的功能A和功能B,这些功能可以是远程的服务也可以是本地化的组件（介绍模块化的必要）。
- 而文章中主要讨论的问题就是如何在Hello中调用这些功能HelloWorld,HelloJava（介绍类与类关系的必要）。
- 在应用程序中控制的就是在当前的应用程序中new来控制插件的实例化。现在应用程序不在关注插件的实例化，交由框架（装配器）进行实例化（把控制权交出去了）这就是所说的控制反转。
- 而框架在实例化的时候通常采用两种方式：依赖注入（将实例化的插件放入IOC容器中）和服务定位（通过服务定位器来获取实例化的插件，由内部的装配器负责实例化，服务定位器只负责获取），两者更清晰的区别可以对比原文的两种方式的图例。
- 依赖注入的三种方式：接口方式，Setter方式，构造器方式。都是通过方法来注入实例化的依赖，不同的是方法的类别不同：接口方式的方法是实现接口中定义的方法来注入，Setter方式是通过属性的setter方法注入，构造器方式则是通过构造方法来注入。
- 服务定位器的两种方式：静态的是将依赖定义为属性，动态的是将依赖放入定义的容器对象中。
- 这些技术都能够达到控制反转的目的，根据不同的需要选择不同的方式实现即可。
简单来说，控制反转和依赖注入就是在描述一件事。
控制反转提出问题：我是应用程序，我不想关注我所依赖的对象是怎么创建的了。我把创建对象的控制权交出去了，具体怎么实现我不管，我只负责拿来用就可以了。
依赖注入解决问题：我是装配器（容器），我来负责创建对象，这件事我比较擅长（当然别人也可以做到比如说服务定位器，Service Locator）。而且我可以通过三种方式创建：接口，Setter,构造器。
4、总结
如果对一个问题表达的不清楚，只能说明理解的不够深入和透彻。当能够用自己的方式表达出正确的意思，那么应该算得上真正掌握吧。