Design Principles and Design Patterns(设计原则与设计模式) -Robert C. Martin

What is software architecture? The answer is multitiered. At the highest level, there are the architecture patterns that define the overall shape and structure of software applications. Down a level is the architecture that is specifically related to the purpose of the software application. Yet another level down resides the architecture of the modules and their interconnections. This is the domain of design patterns, packakges,components, and classes. It is this level that we will concern ourselves with in this chapter.

      什么是软件架构？ 软件架构分为多个层次。最高层的架构模式定义了软件全局的形状和结构。下一层是和特定软件的用途相关的架构。再下一层是和软件中的模块和各个模块间交互相关的架构，这属于设计模式，包，组件和类的领域。本章节中我们主要关注这一层次。

Our scope in this chapter is quite limitted. There is much more to be said about the principles and patterns that are exposed here. Interested readers are referred to.

    本章节涉及的范围有限。本文提到的设计原则和模式还有很多内容，有兴趣的读者可以查询相关的文章。

Architecture and Dependencies（架构和依赖）

What goes wrong with software? The design of many software applications begins as a vital image in the minds of its designers. At this stage it is clean, elegant, and compelling. It has a simple beauty that makes the designers and implementers itch to see it working. Some of these applications manage to maintain this purity of design through the initial development and into the first release.

        软件有什么问题？软件最初来自于设计者头脑中一个重要的想法，此时它是清晰的，优雅的，引人注目的。此时的软件有一种简单的美感，让设计者和实现者急于想看到它完成后是如何工作的。但只有有一部分软件在从开始的开发到最后的发布的过程中成功地保持了设计时的清晰和优雅。
But then something begins to happen. The software starts to rot. At first it isn’t so bad. An ugly wart here, a clumsy hack there, but the beauty of the design still shows through. Yet, over time as the rotting continues, the ugly festering sores and boils accumulate until they dominate the design of the application. The program becomes a festering mass of code that the developers find increasingly hard to maintain. Eventually the sheer effort required to make even the simplest of changes to the application becomes so high that the engineers and front line managers cry for a redesign project.
   但一些不好的事情发生了。软件开始“腐烂”。最初还不是太坏，代码中出现了一些丑陋的“瘤子”和笨拙的“技巧”，但还可以看到最初设计时的优雅。但是，腐烂随着时间继续，丑陋的代码开始扩散，直到这些代码主导了整个软件。开发者发现越来越难以维护这些大量腐烂的代码。最终哪怕只是对软件进行最简单的一个修改也变得非常困难，工程师和一线经理开始哀求重新设计整个项目。

Such redesigns rarely succeed. Though the designers start out with good intentions,they find that they are shooting at a moving target. The old system continues to
evolve and change, and the new design must keep up. The warts and ulcers accumulate in the new design before it ever makes it to its first release. On that fateful day,
usually much later than planned, the morass of problems in the new design may be so bad that the designers are already crying for another redesign.

    重新设计项目的努力很少成功。尽管设计者最初有很好的动机，但他们很快发现他们是在“试图射击移动的靶子”。老的系统在不停地演进和变化，新的设计必须要求跟上这些变化。就像软件的第一个版本一样，"瘤子"和“溃疡”在新设计的版本中累积。很快，新的设计又陷入“泥沼”，设计者开始哀求再一次重新设计。

Symptoms of Rotting Design（腐烂设计的症状）

There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity.

    有四个主要的症状，可以告诉我们软件的设计正在“腐烂”。刚性、脆弱、固定和粘度。

Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multiweek marathon of change in module after module as the engineers chase the thread of the change through the application.

    刚性:刚性指软件很难以改变，即便是很简单的变化。对软件的每一个小的改变都会导致关联模块的一系列多米诺骨牌式的变化。最终1个模块的只花费两天的改变最终成为花费开发者几个星期的模块接模块的马拉松式的修改。

When software behaves this way, managers fear to allow engineers to fix non-critical problems. This reluctance derives from the fact that they don’t know, with any reliability,when the engineers will be finished. If the managers turn the engineers loose on such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel -- engineers check in, but they don’t check out.

   当软件具有刚性的特征时，管理者害怕让工程师修复不致命的故障。因为他们无法知道一旦开始，工程师什么时候能够结束对软件修改。如果管理者放手让工程师去处理这些故障，工程师们可能因此花费很长的时间。软件设计开始变得像一个蟑螂捕捉器——蟑螂(工程师)进去了，但再也出不来了。

When the manager’s fears become so acute that they refuse to allow changes to software,official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.

      当管理者的恐惧变得非常严重时，他们拒绝软件的任何修改。这又在软件中引入了“官方的的刚性”。最开始的设计时的缺陷导致了最终的管理策略的问题。

Fragility. Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.

      脆弱：”脆弱"和"刚性"有密切的关联。脆弱指软件的每一个变化都会导致软件将被打碎成为多个碎片。而被“打碎”的模块代码经常和被修改的模块代码之间没有概念上的关联。这种错误给管理者强烈的预感：每一次他们允许对代码进行修改，他们都害怕软件的某一部分未知的代码被“打碎”。

As the fragility becomes worse, the probability of breakage increases with time,asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved.

    当软件的“脆弱”变得越来越严重时，软件被“打碎”的可能性就越高，几率逼近100%。这样的软件很难维护，因为每修复一个故障，软件就变得更脆弱，并引入更多的问题。

Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.

    这样的软件让经理和客户开始怀疑开发人员已经失去了对软件的控制。不信任的情绪开始蔓延，软件的信用开始丢失。

Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.

      固定：“固定”是指软件代码无法被其他项目或者同一项目的其他部分重用。这种情况发生在软件工程师发现自己需要的一个模块和另一工程师已编写的软件模块功能非常近似时，或者发现一个软件模块依赖了太多的外部模块，需要对该模块进行重构时。但经过大量工作后，工程师发现尝试把需要的软件代码从软件的其余部分分开的风险大得难以容忍。因此他们最终重写了代码，而不是重用已有的代码。

Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
    粘度：“粘度”来自于两方面：设计和环境。当软件面临变化时，软件工程师们会找到多种方法来修改软件。有些方法能够保留设计时的架构，其他方法则不能。当这些能够保留设计时良好结构的方法比其他方法更难以实施时，我们称之为“设计的粘度很高”。即该设计使软件工程师面临软件的变化时，很容易做错误的事，而难以做正确的事（保留设计时的软件架构）。
Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
    环境的粘度来自于开发环境的缓慢与低效。例如，如果编译时间非常长，工程师们会执行那些能够避免引发大规模编译的改动方案，即使这些方案从设计角度来看并不是最优的。 如果需要花费数小时来提交几个文件到源码控制系统，工程师们会尽量执行那些能够减少提交文件次数的修改发难，不管这些方案是否能够保留设计时的软件架构。