1 IoC理论的背景
我们都知道，在采用面向对象方法设计的软件系统中，它的底层实现都是由N个对象组成的，所有的对象通过彼此的合作，最终实现系统的业务逻辑。
图1：软件系统中耦合的对象
如果我们打开机械式手表的后盖，就会看到与上面类似的情形，各个齿轮分别带动时针、分针和秒针顺时针旋转，从而在表盘上产生正确的时间。图1中描述的就是这样的一个齿轮组，它拥有多个独立的齿轮，这些齿轮相互啮合在一起，协同工作，共同完成某项任务。我们可以看到，在这样的齿轮组中，如果有一个齿轮出了问题，就可能会影响到整个齿轮组的正常运转。
齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。现在，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。
图2：对象之间复杂的依赖关系
耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中，很多的J2EE项目均采用了IOC框架产品Spring。 阅读全文 [转]IoC框架
DW/BI Modeling Best Practices
- Do some initial architecture envisioning. At the beginning of a project, during Iteration 0 (see Figure 1), you want to do some initial architecture modeling to identify a potential vision for how your team will build the data warehouse. As Agile Model Driven Development (AMDD) suggests, you do not need to create a comprehensive, detailed model up front, you only need a high-level vision at the beginning of the project and the details can be identified on a just-in-time (JIT) basis via model storming. Sometimes a simple whiteboard sketch is all you need to understand your architectural vision. If so, then just do that. For a BI/DW project, the initial architecture views would likely be some form of deployment diagram capturing the technologies you intend to use and a high-level domain model overviewing the business entities and the relationships between them.
阅读全文 Agile Best Practices for Data Warehousing (DW)/Business Intelligence (BI) Projects By Scott W. Ambler
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
阅读全文 Manifesto for Agile Software Development
作者：彭晨阳，网名banq
多变且复杂的需求
如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。
需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质，就是专门的建模专家也不例外。
既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的 以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件 变化就有多快。
因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性 和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求， 在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。
在这里稍微说明一下，很多人总是将软件和数学、管理、财务混为一谈，其实软件本身就是一门独立的专业，是为 数学、管理。财务等专业领域服务的，不能期望软件人员也是其他领域专业人员，可是在中国现实中，很多人总是 无法分辨，例如某局长将整个机关考核信息化的任务交给电脑中心，这就是将考核管理专业和软件专业混同的例子， 在考核管理和软件之间需要一个领域建模专家，由他来理解或者设计考核管理体系，然后通过模型，表达成 软件人员能够看懂的符号，软件人员通过模型了解领域。
曾经有需求专家呼吁：最好将需求给所有软件人员都了解，需求专家和一般软件人员一起工作，这些想法的本质是 好的，但是不可能实现的，不可能每个软件人员不但了解软件架构和OO思想；还能够掌握另外一个专业领域的艰深知识， 所以，现在我们提出：将领域专家建立的统一领域模型让所有软件人员都了解，让一般软件人员围绕领域模型工作，这样 的方式才切实可行。
阅读全文 面向对象与领域建模
| Most modern business application development projects use object technology such as Java or C# to build the applation software and relational databases to store the data. This isn’t to say that you don’t have other options, there are many applications built with procedural languages such as COBOL and many systems will use object databases or XML databases to store data. However, because object and relational technologies are by far the norm that’s what I assume you’re working with in this article. If you’re working with different storage technologies then many of the concepts are still applicable, albeit with modification (don’t worry, Realistic XML overviews mapping issues pertaining to objects and XML). |
|
Unfortunately we need to deal with the object relational (O/R) impedance mismatch, and to do so you need to understand two things: the process of mapping objects to relational databases and how to implement those mappings. in this article the term “mapping” will be used to refer to how objects and their relationships are mapped to the tables and relationships between them in a database. As you’ll soon find out it isn’t quite as straightforward as it sounds although it isn’t too bad either.
阅读全文 Mapping Objects to Relational Databases: O/R Mapping In Detail By Scott W. Ambler
作者：张逸
一个外部具体对象的引入，必然会给一个模块带来与外部模块之间的依赖。而具体对象的创建始终是我们无法规避的。即使我们可以利用设计模式的工厂方法模式或抽象工厂封装具体对象创建的逻辑，但却又再次引入了具体工厂对象的创建依赖。虽然在设计上有所改进，但没有彻底解除具体依赖，仍让我心有戚戚焉。
阅读全文 解除具体依赖的技术
作者：张逸
没有对象协作的系统是不可想象的，因为此时的系统就是一个庞大的类，一个无所不知的“上帝类”。每个对象都有自己的自治领域，“各人自扫门前雪”， 对象定义的法则就是这么自私。单一职责原则（SRP）[1]体现的正是这样的道理。对象的职责越少，则对象之间的依赖就越少。这一前提就是对象具有足够的 高内聚与细粒度。这样的对象一方面有利于对象的重用，另一方面也保证了对象的稳定性。
对象的职责可以是自己承担，也可以委派给其他对 象。因此，有对象就必然有依赖，正如有人就有江湖。那么，我们该如何降低对象之间的依赖？第一要则是依赖于抽象，如依赖倒置原则（DIP）[2]所云。如 果无法依赖于抽象，则至少应该保证你所依赖的对象是足够稳定的。事实上，最稳定的对象就是抽象对象，所以万法归一，稳定才是降低依赖的基础。
依赖之殇的源头是“变化”。变化与稳定显然是矛盾的，软件设计的最大问题就是如何协调这两者之间的矛盾。我们需要像高明的杂技师，要学会掌握平衡，能够在钢丝绳上无碍的行走。那么，如何解决变化带来的影响呢？答案是利用封装来隔离变化。
阅读全文 依赖之殇
