标题 & 代码高亮

docs/ch12.md

@@ -1,4 +1,4 @@
-Emergence
+# 第 12 章 Emergence
 by Jeff Langr
 
 Image
@@ -40,18 +40,18 @@ During this refactoring step, we can apply anything from the entire body of know
 
 NO DUPLICATION
 Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity. Duplication manifests itself in many forms. Lines of code that look exactly alike are, of course, duplication. Lines of code that are similar can often be massaged to look even more alike so that they can be more easily refactored. And duplication can exist in other forms such as duplication of implementation. For example, we might have two methods in a collection class:
-
+```java
    int size() {}
    boolean isEmpty() {}
-
+```
 We could have separate implementations for each method. The isEmpty method could track a boolean, while size could track a counter. Or, we can eliminate this duplication by tying isEmpty to the definition of size:
-
+```java
    boolean isEmpty() {
       return 0 == size();
    }
-
+```
 Creating a clean system requires the will to eliminate duplication, even in just a few lines of code. For example, consider the following code:
-
+```java
    public void scaleToOneDimension(
         float desiredDimension, float imageDimension) {
      if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
@@ -72,10 +72,10 @@ Creating a clean system requires the will to eliminate duplication, even in just
       System.gc();
       image = newImage;
    }
-
+```
 To keep this system clean, we should eliminate the small amount of duplication between the scaleToOneDimension and rotate methods:
 
-
+```java
    public void scaleToOneDimension(
         float desiredDimension, float imageDimension) {
      if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
@@ -93,11 +93,11 @@ To keep this system clean, we should eliminate the small amount of duplication b
       System.gc();
       image = newImage;
    }
-
+```
 As we extract commonality at this very tiny level, we start to recognize violations of SRP. So we might move a newly extracted method to another class. That elevates its visibility. Someone else on the team may recognize the opportunity to further abstract the new method and reuse it in a different context. This “reuse in the small” can cause system complexity to shrink dramatically. Understanding how to achieve reuse in the small is essential to achieving reuse in the large.
 
 The TEMPLATE METHOD2 pattern is a common technique for removing higher-level duplication. For example:
-
+```java
    public class VacationPolicy {
       public void accrueUSDivisionVacation() {
          // code to calculate vacation based on hours worked to date
@@ -117,11 +117,11 @@ The TEMPLATE METHOD2 pattern is a common technique for removing higher-level dup
          // …
       }
    }
-
+```
 The code across accrueUSDivisionVacation and accrueEuropeanDivisionVacation is largely the same, with the exception of calculating legal minimums. That bit of the algorithm changes based on the employee type.
 
 We can eliminate the obvious duplication by applying the TEMPLATE METHOD pattern.
-
+```java
    abstract public class VacationPolicy {
       public void accrueVacation() {
          calculateBaseVacationHours();
@@ -146,7 +146,7 @@ We can eliminate the obvious duplication by applying the TEMPLATE METHOD pattern
           // EU specific logic
       }
    }
-
+```
 The subclasses fill in the “hole” in the accrueVacation algorithm, supplying the only bits of information that are not duplicated.
 
 EXPRESSIVE