eeymoo/Clean-Code-zh
1
0
Fork 0
mirror of https://github.com/glen9527/Clean-Code-zh.git synced 2025-12-18 03:04:21 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

md 引入图片资源

Browse Source
This commit is contained in:
gdut-yy
2020-01-01 17:11:49 +08:00
parent 9085df5a8e
commit 7a4601dd50
19 changed files with 246 additions and 329 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/ch11.md
View File

@@ -1,7 +1,7 @@
# 第 11 章 Systems
by Dr. Kevin Dean Wampler
Image
![](figures/ch11/11_1fig_martin.jpg)
“Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test.”
@@ -54,7 +54,7 @@ Sometimes, of course, we need to make the application responsible for when an ob
Figure 11-1 Separating construction in main()
Image
![](figures/ch11/11_2fig_martin.jpg)
LineItem instances to add to an Order. In this case we can use the ABSTRACT FACTORY2 pattern to give the application control of when to build the LineItems, but keep the details of that construction separate from the application code. (See Figure 11-2.)
@@ -63,7 +63,7 @@ LineItem instances to add to an Order. In this case we can use the ABSTRACT FACT
Figure 11-2 Separation construction with factory
Image
![](figures/ch11/11_3fig_martin.jpg)
Again notice that all the dependencies point from main toward the OrderProcessing application. This means that the application is decoupled from the details of how to build a LineItem. That capability is held in the LineItemFactoryImplementation, which is on the main side of the line. And yet the application is in complete control of when the LineItem instances get built and can even provide application-specific constructor arguments.
@@ -328,7 +328,7 @@ Each “bean” is like one part of a nested “Russian doll,” with a domain o
Figure 11-3 The “Russian doll” of decorators
Image
![](figures/ch11/11_4fig_martin.jpg)
The client believes it is invoking getAccounts() on a Bank object, but it is actually talking to the outermost of a set of nested DECORATOR14 objects that extend the basic behavior of the Bank POJO. We could add other decorators for transactions, caching, and so forth.