replace 臵 with 置

docs/ch1.md

@@ -66,7 +66,7 @@ They constantly corrected me, and as they did I started to learn. We ironed out
 
 To focus our exploration, we limited ourselves, for a while, to studying one particular feature. A “probe simulation” would trace the propagation of a signal to detect likely sites of certain kinds of problems in the design.
 
-> 为了让讨论更集中，接下来的一段时间我们探讨了一个特定的功能：探针仿真（probesimulation）。探针仿真跟踪信号的传播，以便检测在设计中可能出现特定类型问题的位臵。
+> 为了让讨论更集中，接下来的一段时间我们探讨了一个特定的功能：探针仿真（probesimulation）。探针仿真跟踪信号的传播，以便检测在设计中可能出现特定类型问题的位置。
 
 - Developer: I understand how the signal gets carried by the Net to all the Pins attached, but how does it go any further than that? Does the Topology have something to do with it?
 - Expert 2: No. The component pushes the signal through.

docs/ch10.md

@@ -174,7 +174,7 @@ But in the next two patterns, we’ll set out to make the consequences of using
 
 Operations can be broadly divided into two categories, commands and queries. Queries obtain information from the system, possibly by simply accessing data in a variable, possibly performing a calculation based on that data. Commands (also known as modifiers) are operations that affect some change to the systems (for a simple example, by setting a variable). In standard English, the term side effect implies an unintended consequence, but in computer science, it means any effect on the state of the system. For our purposes, let’s narrow that meaning to any change in the state of the system that will affect future operations.
 
-> 我们可以宽泛地把操作分为两个大的类别：命令和查询。查询是从系统获取信息，查询的方式可能只是简单地访问变量中的数据，也可能是用这些数据执行计算。命令（也称为修改器）是修改系统的操作（举一个简单的例子，设臵变量）。在标准英语中，“副作用”这个词暗示着“意外的结果”，但在计算机科学中，任何对系统状态产生的影响都叫副作用。这里为了便于讨论，我们把它的含义缩小一下，任何对未来操作产生影响的系统状态改变都可以称为副作用。
+> 我们可以宽泛地把操作分为两个大的类别：命令和查询。查询是从系统获取信息，查询的方式可能只是简单地访问变量中的数据，也可能是用这些数据执行计算。命令（也称为修改器）是修改系统的操作（举一个简单的例子，设置变量）。在标准英语中，“副作用”这个词暗示着“意外的结果”，但在计算机科学中，任何对系统状态产生的影响都叫副作用。这里为了便于讨论，我们把它的含义缩小一下，任何对未来操作产生影响的系统状态改变都可以称为副作用。
 
 Why was the term side effect adopted and applied to quite intentional changes affected by operations? I assume this was based on experience with complex systems. Most operations call on other operations, and those called invoke still other operations. As soon as this arbitrarily deep nesting is involved, it becomes very hard to anticipate all the consequences of invoking an operation. The developer of the client may not have intended the effects of the second-tier and third-tier operations—they’ve become side effects in every sense of the phrase. Elements of a complex design interact in other ways that are likely to produce the same unpredictability. The use of the term side effect underlines the inevitability of that interaction.
 
@@ -297,11 +297,11 @@ When the side effects of operations are only defined implicitly by their impleme
 
 We need a way of understanding the meaning of a design element and the consequences of executing an operation without delving into its internals. INTENTION-REVEALING INTERFACES carry us part of the way there, but informal suggestions of intentions are not always enough. The “design by contract” school goes the next step, making “assertions” about classes and methods that the developer guarantees will be true. This style is discussed in detail in Meyer 1988. Briefly, “post-conditions” describe the side effects of an operation, the guaranteed outcome of calling a method. “Preconditions” are like the fine print on the contract, the conditions that must be satisfied in order for the post-condition guarantee to hold. Class invariants make assertions about the state of an object at the end of any operation. Invariants can also be declared for entire AGGREGATES, rigorously defining integrity rules.
 
-> 我们需要在不深入研究内部机制的情况下理解设计元素的意义和执行操作的后果。INTENTION-REVEALING INTERFACE 可以起到一部分作用，但这样的接口只能非正式地给出操作的用途，这常常是不够的。“契约式设计”（design by contract）向前推进了一步，通过给出类和方法的“断言”使开发人员知道肯定会发生的结果。[Meyer 1988]中详细讨论了这种设计风格。简言之，“后臵条件”描述了一个操作的副作用，也就是调用一个方法之后必然会发生的结果。“前臵条件”就像是合同条款，即为了满足后臵条件而必须要满足的前臵条件。类的固定规则规定了在操作结束时对象的状态。也可以把 AGGREGATE 作为一个整体来为它声明固定规则，这些都是严格定义的完整性规则。
+> 我们需要在不深入研究内部机制的情况下理解设计元素的意义和执行操作的后果。INTENTION-REVEALING INTERFACE 可以起到一部分作用，但这样的接口只能非正式地给出操作的用途，这常常是不够的。“契约式设计”（design by contract）向前推进了一步，通过给出类和方法的“断言”使开发人员知道肯定会发生的结果。[Meyer 1988]中详细讨论了这种设计风格。简言之，“后置条件”描述了一个操作的副作用，也就是调用一个方法之后必然会发生的结果。“前置条件”就像是合同条款，即为了满足后置条件而必须要满足的前置条件。类的固定规则规定了在操作结束时对象的状态。也可以把 AGGREGATE 作为一个整体来为它声明固定规则，这些都是严格定义的完整性规则。
 
 All these assertions describe state, not procedures, so they are easier to analyze. Class invariants help characterize the meaning of a class, and simplify the client developer’s job by making the objects more predictable. If you trust the guarantee of a post-condition, you don’t have to worry about how a method works. The effects of delegations should already be incorporated into the assertions.
 
-> 所有这些断言都描述了状态，而不是过程，因此它们更易于分析。类的固定规则在描述类的意义方面起到帮助作用，并且使客户开发人员能够更准确地预测对象的行为，从而简化他们的工作。如果你确信后臵条件的保证，那么就不必考虑方法是如何工作的。断言应该已经把调用其他操作的效果考虑在内了。
+> 所有这些断言都描述了状态，而不是过程，因此它们更易于分析。类的固定规则在描述类的意义方面起到帮助作用，并且使客户开发人员能够更准确地预测对象的行为，从而简化他们的工作。如果你确信后置条件的保证，那么就不必考虑方法是如何工作的。断言应该已经把调用其他操作的效果考虑在内了。
 
 Therefore:
 
@@ -317,11 +317,11 @@ Seek models with coherent sets of concepts, which lead a developer to infer the
 
 Even though many object-oriented languages don’t currently support ASSERTIONS directly, ASSERTIONS are still a powerful way of thinking about a design. Automated unit tests can partially compensate for the lack of language support. Because ASSERTIONS are all in terms of states, rather than procedures, they make tests easy to write. The test setup puts the preconditions in place; then, after execution, the test checks to see if the post-conditions hold.
 
-> 尽管很多面向对象的语言目前都不支持直接使用 ASSERTION，但 ASSERTION 仍然不失为一种功能强大的设计方法。自动单元测试在一定程度上弥补了缺乏语言支持带来的不足。由于 ASSERTION 只声明状态，而不声明过程，因此很容易编写测试。测试首先设臵前臵条件，在执行之后，再检查后臵条件是否被满足。
+> 尽管很多面向对象的语言目前都不支持直接使用 ASSERTION，但 ASSERTION 仍然不失为一种功能强大的设计方法。自动单元测试在一定程度上弥补了缺乏语言支持带来的不足。由于 ASSERTION 只声明状态，而不声明过程，因此很容易编写测试。测试首先设置前置条件，在执行之后，再检查后置条件是否被满足。
 
 Clearly stated invariants and pre- and post-conditions allow a developer to understand the consequences of using an operation or object. Theoretically, any noncontradictory set of assertions would work. But humans don’t just compile predicates in their heads. They will be extrapolating and interpolating the concepts of the model, so it is important to find models that make sense to people as well as satisfying the needs of the application.
 
-> 把固定规则、前臵条件和后臵条件清楚地表述出来，这样开发人员就能够理解使用一个操作或对象的后果。从理论上讲，如果一组断言之间互不矛盾，那么就可以发挥作用。但人的大脑并不会一丝不苟地把这些断言编译到一起。人们会推断和补充模型的概念，因此找到一个既易于理解又满足应用程序需求的模型是至关重要的。
+> 把固定规则、前置条件和后置条件清楚地表述出来，这样开发人员就能够理解使用一个操作或对象的后果。从理论上讲，如果一组断言之间互不矛盾，那么就可以发挥作用。但人的大脑并不会一丝不苟地把这些断言编译到一起。人们会推断和补充模型的概念，因此找到一个既易于理解又满足应用程序需求的模型是至关重要的。
 
 Example: Back to Paint Mixing
 
@@ -339,7 +339,7 @@ The receiver’s volume is increased by the amount of the argument’s volume. D
 
 To start on a solid footing, let’s state the post-condition of the mixIn() method as it is:
 
-> 第一步，我们先把 `mixIn()` 方法的后臵条件声明如下：
+> 第一步，我们先把 `mixIn()` 方法的后置条件声明如下：
 
 ```
 After p1.mixIn(p2):
@@ -363,7 +363,7 @@ But wait! While developers were pondering this option, they made a discovery. It
 
 So, to make the volume model logically consistent would make it unsuitable for its application requirements. There seems to be a dilemma. Are we stuck with documenting the weird post-condition and trying to compensate with good communication? Not everything in this world is intuitive, and sometimes that is the best answer. But in this case, the awkwardness seems to point to missing concepts. Let’s look for a new model.
 
-> 因此，如果要使体积模型的逻辑保持一致，那么它就无法满足这个应用程序的需求了。这看上去是一种进退两难的境况。我们是否仍使用这个不合常理的后臵条件，并为了弥补这个不足而清楚地说明这样做的理由呢？世界上并不是一切事物都是直观的，有时那就是最好的答案。但在这个例子中，这种尴尬局面似乎是由于丢失概念而造成的。让我们去寻找一个新的模型。
+> 因此，如果要使体积模型的逻辑保持一致，那么它就无法满足这个应用程序的需求了。这看上去是一种进退两难的境况。我们是否仍使用这个不合常理的后置条件，并为了弥补这个不足而清楚地说明这样做的理由呢？世界上并不是一切事物都是直观的，有时那就是最好的答案。但在这个例子中，这种尴尬局面似乎是由于丢失概念而造成的。让我们去寻找一个新的模型。
 
 We Can See Clearly Now
 
@@ -404,7 +404,7 @@ public void testMixingVolume {
 
 This model captures and communicates more of the domain. The invariants and post-conditions make common sense, which will make them easier to maintain and use.
 
-> 这个模型捕捉并传递了更多领域知识。固定规则和后臵条件符合常识，这使得它们更易于维护和使用。
+> 这个模型捕捉并传递了更多领域知识。固定规则和后置条件符合常识，这使得它们更易于维护和使用。
 
 ---
 
@@ -699,7 +699,7 @@ Generating a running program from a declaration of model properties is a kind of
 
 The unintended consequence of many attempts at declarative design is the dumbing-down of the model and application, as developers, trapped by the limitations of the framework, enact design triage in order to get something delivered.
 
-> 许多声明式设计的尝试带来了意想不到的后果，由于开发人员受到框架局限性的约束，为了交付工作只能先处理重要问题，而搁臵其他一些问题，这导致模型和应用程序的质量严重下降。
+> 许多声明式设计的尝试带来了意想不到的后果，由于开发人员受到框架局限性的约束，为了交付工作只能先处理重要问题，而搁置其他一些问题，这导致模型和应用程序的质量严重下降。
 
 Rule-based programming with an inference engine and a rule base is another promising approach to declarative design. Unfortunately, subtle issues can undermine this intention.
 
@@ -743,7 +743,7 @@ A different paradigm might handle domain-specific languages better than objects.
 
 This technique might be most useful for very mature models, perhaps where client code is being written by a different team. Generally, such setups lead to the poisonous distinction between highly technical framework builders and technically unskilled application builders, but it doesn’t have to be that way.
 
-> 这种技术也许能在非常成熟的模型中发挥出最大的作用，在这种情况下，客户代码可能是由不同的团队编写的。但一般情况下，这样的设臵会产生有害的结果——团队被分成两部分，框架由那些技术水平较高的人来构建，而应用程序则由那些技术水平较差的人来构建了，但也并不是非得如此。
+> 这种技术也许能在非常成熟的模型中发挥出最大的作用，在这种情况下，客户代码可能是由不同的团队编写的。但一般情况下，这样的设置会产生有害的结果——团队被分成两部分，框架由那些技术水平较高的人来构建，而应用程序则由那些技术水平较差的人来构建了，但也并不是非得如此。
 
 In the scheme programming language, something very similar is part of standard programming style, so that the expressiveness of a domain-specific language can be created without bifurcating the system.
 
@@ -789,7 +789,7 @@ public interface Specification {
 
 This abstraction calls for a guard clause at the beginning of the method, but otherwise it does not affect functionality. For example, the Container Specification (from the example in Chapter 9, on page 236) would be modified this way:
 
-> 这个抽象要求在方法的开始处放臵一条卫语句（guard clause），但是没有卫语句也不影响它的功能。例如，可以对 Container Specification（参见图 9-16 以及后面的相关表格、代码等）做如下修改：
+> 这个抽象要求在方法的开始处放置一条卫语句（guard clause），但是没有卫语句也不影响它的功能。例如，可以对 Container Specification（参见图 9-16 以及后面的相关表格、代码等）做如下修改：
 
 ```java
 public class ContainerSpecification implements Specification {

docs/ch12.md

@@ -66,7 +66,7 @@ A Route Specification is being passed to a Routing Service, whose job is to cons
 
 This setup looks OK, but a detailed look at the routing code would reveal conditionals in every computation, making the decision between fastest or cheapest appear all over the place. More trouble will come when new criteria are added to make more subtle choices between routes.
 
-> 这种设臵看上去似乎没问题，但仔细观察路线代码就会发现，每个计算中都有条件判断，判断最快还是最便宜的逻辑分散在程序各处。当为了做出更精细的航线选择而把新标准添加进来时，麻烦会更多。
+> 这种设置看上去似乎没问题，但仔细观察路线代码就会发现，每个计算中都有条件判断，判断最快还是最便宜的逻辑分散在程序各处。当为了做出更精细的航线选择而把新标准添加进来时，麻烦会更多。
 
 One approach is to separate those tuning parameters into STRATEGIES. Then they can be represented explicitly, passed into the Routing Service as a parameter.
 

docs/ch13.md

@@ -68,7 +68,7 @@ There are a few keys to keeping this process productive.
 
 Earlier chapters in this book have presented several dialogs in which developers and domain experts probe for better models. A full-blown brainstorming session is dynamic, unstructured, and incredibly productive.
 
-> 本书前面几章曾介绍过开发人员和领域专家为了设计更好的模型而进行的几段对话。成熟的头脑风暴是灵活机动、不拘泥于形式的，而且具有令人难以臵信的高效率。
+> 本书前面几章曾介绍过开发人员和领域专家为了设计更好的模型而进行的几段对话。成熟的头脑风暴是灵活机动、不拘泥于形式的，而且具有令人难以置信的高效率。
 
 ## 13.3 PRIOR ART 借鉴先前的经验