reducing doupling(1)

One of the earliest indicators of design quality was coupling. It appeared, together with cohesion, in the earliest
works in structured design, and it has never gone away. I still always think of it when considering a software design.There are several ways to describe coupling,but it boils down to this: If changing one module in a program requires changing another module, then coupling exists. It might be that the two modules do similar things at one point, so the code in one module is effectively a duplicate of the code in the other. This is an example of the primary and obvious sin of duplication. Duplication always implies coupling,because changing one piece of duplicate code implies changing the other. It can also be hard to spot, because there might not be an obvious relationship between the two pieces of code. 

耦合度，是最早的良好软件设计的指标之一。它和内聚性一起出现在结构设计的最早的文献中，现在也没有衰退。当进行软件设计时我依旧在思考这个问题。有一些方法说明什么是耦合度， 它几乎都归结为：如果改变在一个程序中的模块，需要改变另外一个模块，那么就存在耦合。俩个模块在一个方面做相似的事情,这个是很有可能的，那么这个模块的代码实际上是复制了另一个模块的代码。这个例子说明了复制代码主要且明显的缺陷。复制就意味着耦合，因为改变一条复制的代码意味着改变另一个代码。但这个很难发现，因为在这两条代码之间没有明显的关系。

Coupling also occurs when code in one module uses code from another, perhaps by calling a function or accessing some data. At this point, it becomes clear that, unlike duplication,you can’t treat coupling as something to always avoid. You can break a program into modules, but these modules will need to communicate in some way—otherwise, you’d just have multiple programs. Coupling is desirable,
because if you ban coupling between modules, you have to put everything in one big module. Then, there would be lots of coupling—just all hidden under the rug.So coupling is something we need to control,
but how? Do we worry about coupling everywhere, or is it more important in some places than others? Which factors make coupling bad, and which are permissible?

当一个模块代码使用另一个模块代码，可以是调用一个函数或读取数据，这个时候会发生耦合。，你不可像避免复制那样可以去避免耦合，这一点已经很清楚了。你可以把一个程序分成几个模块，但是这些模块间需要以某种方式通信-----否则，你必须有多个程序。这时耦合是有必要的，因为如果你禁止了模块间的耦合，那就不得不把所有的代码放到一个大模块中。那么，这将有很多的耦合---就像是藏在地毯下一样。所以，我们需要控制耦合度，但该怎么控制呢？我们为了处处出现的耦合焦虑，还是说在某些地方耦合更重要呢？什么因素是耦合变得糟糕，什么因素又是该允许的呢？

   I concern myself most with coupling at the highest-level modules. If we divide a system into a dozen (or fewer) large-scale pieces,how are these pieces coupled? I focus on the coarser-grained modules, because worrying
about coupling everywhere is overwhelming.The biggest problems come from uncontrolled coupling at the upper levels. I don’t worry about the number of modules coupled together, but I look at the pattern of dependency relationship between the modules. I also find a diagram very helpful.

 我个人所关心的是在最高层模型的耦合。如果我们把一个系统分成十几个（或少点）大规模的部分，这些部分如果耦合呢？我专注于更大颗粒的模块，因为担心耦合是不可避免的。上层未控制的耦合是最大的问题。我不担心耦合在一起模块的数量，但是着眼于模块间依赖关系的模式。我还发现了一个很有用的图表。

    When I use the term dependency, I use it as defined in the Unified Modeling Language (UML). So, the UI module depends on the domain module if any code in the UI module references any code in the domain model—by calling a function, using some data,or using types defined in the domain module. If someone changes the domain,there is a chance the UI model will also need to change. A dependency
is unidirectional: The UI module usually depends on the domain module, but not the other way
around. We would have a second dependency if the domain module also depended on the UI module.

   当我们用依赖这个术语的时候，我把他当UML中定义的依赖一样来使用。因此，如果UI模块中任何代码引用了域模型中任何代码，---比如调用函数，访问数据，或引用域模块中的定义的类型，则称依赖。如果有人改变了域，那么UI模块很可能需要更改。依赖不是单向的：UI模块通常依赖域模块，但是也不尽然。如果域模块也依赖UI模块的话我们可以有另一个依赖关系。

    UML dependencies are also nontransitive.If the UI module depends on the domain module, and the domain
module depends on the database module, we can’t assume that the UI module depends on the database
module. If it does, we must describe this with an extra dependency directly between UI and database
modules. This nontransitivity is important because it lets us show that the domain model insulates the UI
from changes in the database. Thus, if the database’s interface changes,we don’t immediately have to worry about a change in the UI. The UI will only change if the change in the database causes a big enough
change in the domain that the domain’s interface also changes.  Figure 1a shows how I’d diagram
this using UML notation. The UML is designed for an OO system, but the basic notion of modules and dependencies applies to most styles of software. The UML name for this kind of high-level module is package,
so I’ll use that term from now  on (so the UML police won’t arrest me!). Because these are packages, I
call this kind of diagram a package diagram (although strictly in UML, it’s a class diagram).

   UML依赖关系也是非传递性的。如果UI层依赖域对象层，域对象层依赖数据层，我们不能说UI层依赖数据层。如果说UI层依赖数据层，我们必须直接的说明UI与数据层的依赖关系。非传递性是很重要的，因为非传递性说明了 域对象层与数据层没有关联。因此，如果数据层接口变了，我们没必要立刻担心UI层的变化。

    What I’m describing here is a layered architecture, which should be familiar to anyone who works in
information systems. The layers in an information system make good fodder for describing things we
must consider when thinking about dependencies.