canonical

    敏捷思想的流行使得很多人对可扩展设计产生了一种怀疑的态度。这有几方面的原因，一方面是J2EE平台本身提供的分布式机制等技术因素很容易诱导你定义不 必要的扩展需求，第二是基于目前的技术手段对于程序结构的分解仍然有着很大限制，具体的程序实现中往往会引入某种强制依赖，削弱了潜在的可扩展性，第三则 是设计者本身对于技术和业务的把握不够深入，在考虑设计的可扩展性时经常做出错误的判断。但是一个只满足当前需求的系统一般不是个好系统，也很难在多次迭 代生命周期后继续生存。XP(extreme programming)强调简单化，其实质在于简单的东西可以在未来被重构(refactor)，从而适应未知的变化，它本身并不排斥可扩展设计。
    从基本的常识出发，我们都知道现在应该为将来做些事情，准备些资本。可扩展设计的价值观不应是现在解决将来的问题，而是寻求未来发展之后现在的解是否仍然 部分有效，是否仍然可以部分被继承。即我们考虑的不是将未来的解纳入到现在的体系中，而是考虑现在的解在未来的体系中的位置。不是在现在如何支持我们所预 想到的几种未来的扩展方式，而是无论未来如何变化，怎样才能保证现在工作的有效性。这里所关注的重点是现在而不是将来!面对演化我们所能采取的最好的策略 就是尽量有所积累，尽量不放弃我们的过去，而不是把宝押在对未来的准确预测上。一个厚重的设计往往在后期会因为预料的太多反而在遭遇未预料到的变化时不知 所措，结果造成系统整体架构的失效，必须做更多的工作打补丁来使得它勉强工作。象EJB这样distribution ready的技术现在已经公认有过度设计之嫌，因为这些已经ready的特性一般并不会被应用但是我们却不得不为这些无用的特性付出代价。
    
    可扩展设计所依赖的基本原则之一是IoC(Inversion of Control)。IoC是目前轻量级容器(lightweight container)的核心设计思想，但其实它的应用远不止在轻量级容器这一领域。基于IoC设计，大量的知识（依赖）被剥离出业务对象本身，对象对于其 生存环境和应用场景的假设大大减弱，而我们的期望正在于无论未来的应用环境如何变化，只要提供必要的知识，业务对象就能工作。可以说，IoC是可扩展性的 一种基本要求。
   
    可扩展设计所依赖的另一个原则是连续性(continuous), 这可比IoC要复杂和深刻的多了。如果说现代设计的核心观念是演化(evolution), 那么在我们的思想中演化到底有着什么样的图景？ 至少需要一个方向加上一条连续的途径,evolution才能发生。在级列设计中，一个简单的系统架构需要能够scale up，而一个复杂层次上的系统架构也需要能够以优雅的方式scale down。这种变化是自然的因为它们是连续的。