敏捷软件开发（影印版）

.continuous integration
sustainable pace
open workspace
the planning game
simple design
refactoring
metaphor
conclusion
bibliography
chapter3 planning
initial exploration
spiking, splitting, and velocity
release planning
iteration planning
task planning
the halfway point
iterating
conclusion
bibliography
chapter 4 testing
test driven development
an example of test-first design
test isolation
serendipitous de. coupling
acceptance tests
example of acceptance testing
serendipitous architecture
conclusion
bibliography
chapter 5 refactoring
generating primes: a simple example of refactoring
the final reread
conclusion
bibliography
chapter 6 a programming episode
the bowling game
conclusion
section 2 agile design
symptoms of poor design
principles
smells and principles
bibliography
chapter 7 what is agile design?
what goes wrong with software?
design smells--the odors of rotting software
what stimulates the software to rot?
agile teams don't allow the software to rot
the "copy" program
agile design of the copy example
how did the agile developers know what to do?
keeping the design as good as it can be
conclusion
bibliography
chapter 8 srp: the single-responsibility principle
a class should have only one reason to change.
srp: the single-responsibility principle
what is a responsibility?
separating coupled responsibilities
persistence
conclusion
bibliography
chapter 9 ocp: the open-closed principle
software enttties (classes, modules, functions, etc. ) should be open
for extension, but closed for modification.
ocp: the open-closed principle
description
abstraction is the key
the shape application
violating the ocp
conforming to the ocp
ok, i lied
anticipation and "natural" structure
putting the "hooks" in
using abstraction to gain explicit closure
using a "data-driven" approach to achieve closure
conclusion
bibliography
chapter 10 lsp: the liskov substitution principle
subtypes must be substitutable for their base types.
lsp: the liskov substitution principle
a simple example of a violation of the lsp
square and rectangle, a more subtle violation
the real problem
validity is not intrinsic
isa is about behavior
design by contract
specifying contracts in unit tests
a real example
motivation
problem
a solution that does not conform to the lsp
an lsp-compliant solution
factoring instead of deriving
heuristics and conventions
degenerate functions in derivatives
throwing exceptions from derivatives
conclusion
bibliography
chapter 11 dip: the dependency-inversion principle
a. high-level modules should not depend upon low-level modules.
both should depend on abstractions.
b. abstractions should not depend on details. details should
depend on abstractions.
dip: the dependency-inversion principle
layering
an inversion of ownership
depend on abstractions
a simple example
finding the underlying abstraction
the furnace example
dynamic v. static polymorphism
conclusion
bibliography
chapter 12 isp: the interface-segregation principle
interface pollution
separate clients mean separate interfaces
the backwards force applied by clients upon interfaces
clients should not be forced to depend on methods that they do
not use.
isp: the interface-segregation principle
class interfaces v. object interfaces
separation through delegation
separation through multiple inheritance
the atm user interface example
the polyad v. the monad
conclusion
bibliography
section 3 the payroll case study
rudimentary specification of the payroll system
exercise
use case 1: add new employee
use case 2: deleting an employee
use case 3: post a time card
use case 4: posting a sales receipt
use case 5: posting a union service charge
use case 6: changing employee details
use case 7: run the payroll for today
chapter 13 command and active object
simple commands
transactions
physical and temporal decoupling
temporal decoupling
undo
active object
conclusion
bibliography
chapter 14 template method & strategy: inheritance vs. delegation
template method
pattern abuse
bubble sort
strategy
sorting again
conclusion
bibliography
chapter 15 facade and mediator
facade
mediator
conclusion
bibliography
chapter 16 singleton and monostate
singleton
benefits of the singleton
costs of the singleton
sinoleton in action
monostate
benefits of monostate
costs of monostate
monostate in action
conclusion
bibliography
chapter 17 null object
conclusion
bibliography
chapter 18 the payroll case study: iteration one begins
introduction
specification
analysis by use cases
adding employees
deleting employees
posting time cards
posting sales receipts
posting a union service charge
changing employee details
payday
reflection: what have we learned?
finding the underlying abstractions
the schedule abstraction
payment methods
affiliations
conclusion
bibliography
chapter 19 the payroll case study: implementation
adding employees
the payroll database
using template method to add employees
deleting employees
global variables
time cards, sales receipts, and service charges
changing employees
changing classification
what was i smoking?
paying employees
do we want developers making business decisions?
paying salaried employees
paying hourly employees
pay periods: a design problem
main program
the database
summary of payroll design
history
resources
bibliography
section 4 packaging the payroll system
chapter 20 principles of package design
designing with packages?
granularity: the principles of package cohesion
the reuse-release equivalence principle (rep)
the granule of reuse is the granule of release.
the common-reuse principle (cup)
the classes ina package are reused together. if you reuse one of the
classes in a package, you reuse them all.
the common-closure principle (ccp)
the classes in a package should be closed together against the same
kinds of changes. a change that affects a package affects all the
classes in that package and no other packages.
summary of package cohesion
stability: the principles of package coupling
the acyclic-dependencies principle (adp)
allow no cycles in the package dependency graph.
the weekly build
eliminating dependency cycles
the effect of a cycle in the package dependency graph
breaking the cycle
the "jitters"
top-down design
the stable-dependencies principle (sdp)
depend in the direction of stability.
stability
stability metrics
not all packages should be stable
where do we put the high-level design?
the stable-abstractions principle (sap)
a package should be as abstract as it is stable.
measuring abstraction
the main sequence
distance from the main sequence
conclusion
chapter21 factory
a dependency cycle
substitutable factories
using factories for test fixtures
how important is it to use factories?
conclusion
bibliography
chapter22 the payroll case study (part 2)
package structure and notation
applying the common. closure principle (ccp)
applying the reuse-release equivalency principle (rep)
coupling and encapsulation
metrics
applying the metrics to the payroll application
object factories
the object factory for transactionlmplementation
initializing the factories
rethinking the cohesion boundaries
the final package structure
conclusion
bibliography
section 5 the weather station case study
chapter23 composite
example: composite commands
multiplicity or not multiplicity
chapter 24 observer--backing into a pattern
the digital clock
conclusion
the use of diagrams in this chapter
the observer pattern
how observer manages the principles of ood
bibliography
chapter 25 abstract server, adapter, and bridge
abstract server
who owns the interface?
adapter
the class form of adapter
the modem problem, adapters and lsp
bridge
conclusion
bibliography
chapter 26 proxy and stairway to heaven: managing third party apis
proxy
proxifying the shopping cart
summary of proxy
dealing with databases, middleware, and other third party interfaces
stairway to heaven
example of stairway to heaven
other patterns that can be used with databases
conclusion
bibliography
chapter 27 case study: weather station
the cloud company
the wms-lc software
language selection
nimbus-lc software design
24-hour history and persistence
implementing the hilo algorithms
conclusion
bibliography
nimbus-lc requirements overview
usage requirements
24-hour history
user setup
administrative requirements
nimbus-lc use cases
actors
use cases
measurement history
setup
administration
nimbus-lc release plan
introduction
release i
risks
deliverable(s)
release ii
use cases implemented
risks
deliverable(s)
release iii
use cases implemented
risks
deliverable(s)
section 6 the ets case study
chapter28 visitor
the visitor family of design patterns
visitor
visrror is like a matrix
acyclic visitor
acyclic visitor is like a sparse matrix
using visitor in report generators
other uses of visitor
decorator
multiple decorators
extension object
conclusion
reminder
bibliography
chapter29 state
overview of finite state automata
implementation techniques
nested switch/case statements
interpreting transition tables
the state pattern
smc--the state-machine compiler
where should state machines be used?
high-level application policies for guis
gui interaction controllers
distributed processing
conclusion
listings
turnstile. java using table interpretation
turnstile. java generated by smc, and other support files
bibliography
chapter 30 the ets framework
introduction
project overview
early history 1993-1994
framework?
framework!
the 1994 team
the deadline
the strategy
results
framework design
the common requirements of the scoring applications
the design of the scoring framework
a case for template method
write a loop once
the common requirements of the delivery applications
the design of the delivery framework
the taskmaster architecture
conclusion
bibliography
appendix a uml notation i: the cgi example
course enrollment system: problem description
actors
use cases
the domain model
the architecture
abstract classes and interfaces in sequence diagrams
summary
bibliography
appendix b uml notation ii: the statmux
the statistical multiplexor definition
the software environment
the real-time constraints
the input interrupt service routine
the output service interrupt routine
the communications protocol
conclusion
bibliography
appendix c a satire of two companies
rufus, inc.
project kickoff
rupert industries
project: -alpha-
appendix d the source code is the design
what is software design?
afterword
index

.　　 three are entitled "Iterative and Incremental Development" (I, II, III). The last is entitled "C.O.D.E Culled Object Development process."
　　that we actually used in our projects, they were an unwitting compromise to values that had been imposed upon me for decades. It took Kent Beck to .show me that.
　　 The Beck Connection
　　 In late 1998, as I was fretting over codifying the Object-Mentor process, I ran into Kent's work on Extreme Programming (XP). The work was scattered through Ward Cunningham's wiki2 and was mixed with the writings of many others. Still, with some work and diligence I was able to get the gist of what Kent was talking about. I was intrigued, but skeptical. Some of the things that XP talked about were exactly on target for my concept of a development process. Other things, however, like the lack of an articulated design step, left me puzzled.
　　 Kent and I could not have come from more disparate software circumstances. He was a recognized Smalltalk consultant, and I was a recognized C++ consultant. Those two worlds found it difficult to communicate with one another. There was an almost Kuhnian3 paradigm gulf between them.
　　 Under other circumstances, I would never have asked Kent to write an article for the C++ Report. But the congruence of our thinking about process was able to breech the language gulf. In February of 1999, I met Kent in Munich at the OOP conference. He was giving a talk on XP in the room across from where I was giving a talk on principles of OOD. Being unable to hear that talk, I sought Kent out at lunch. We talked about Xl), and I asked him to write an article for the C++ REport. It was a great article about an incident in which Kent and a coworker had been able to make a sweeping design change in a live system in a matter of an hour or so.
　　 Over the next several months, I went through the slow process of sorting out my own fears about XP. My greatest fear was in adopting a process in which there is no explicit up-front design step. I found myself balking at that. Didn't I have an obligation to my clients, and to the industry as a whole, to teach them that design is important enough to spend time on?
　　 Eventually, I realized that I did not really practice such a step myself. Even in all the articles and books I had written about design, Booch diagrams, and UML diagram.% I had always used code as a way to verify that the diagrams were meaningful. In all my customer consulting, I would spend an hour or two helping them to draw diagrams and then I would direct them to explore those diagrams with code. I came to understand that though XP's words about design were foreign (in a Kuhnian4 sense), the practices behind the words were familiar to me.
　　 My other fears about XP were easier to deal with. I had always been a closet pair programmer. XP gave me a way to come out of the closet and revel in my desire to program with a partner. Refactoring, continuous integration, and customer on-site were all very easy for me to accept. They were very close to the way I already advised my customers to work.
　　 One practice of XP was a revelation for me. Test-first design sounds innocuous when you first hear it. It says to write test cases before you write production code. All production code is written to make failing test cases pass. I was not prepared for the profound ramifications that writing code this way would have. This practice has completely transformed the way I write software, and transformed it for the better. You can see that transformation in this book. Some of the code written in this book was written before 1999. You won't find test cases for that code, On the other hand, all of the code written after 1999 is presented with test cases, and the test cases are typically presented first. I'm sure you'll note the difference.
　　So, by the fall of 19991 was convinced that Object Mentor should adopt XP as its process of choice and that I should let go of my desire to write my own process. Kent had done an excellent job of articulating the practices and process of Xl), and my own feeble attempts paled in comparison.
　　 2. http://c2 com/cgi/wiki. This website contains contains a vast number of articles on an immeuse variety of subjects. Its authors number
　　 in the hundreds or thousands. It has been said that only Ward Cunningham could instigate a social revolution using a few lines of Perl.
　　 3. Any credible intellectual work written between 1995 and 2001 must use the term "Kuhnian." It refers to the book, The Structure of Sci-
　　 entific Revolutions, by Thomas S. Kuim, The University of Chicago Press, 1962.
　　 4. If you mention Kuhn twice in a paper, you get extra credit.
　　Organization
　　This book is organized into six major sections followed by several appendices.
　　 Section 1: Agile Development.
　　 This section describes the concept of agile development. It starts with the Manifesto of the Agile Alliance, provides an overview of Extreme Progranuning (XP), and then goes into many small case studies that illuminate some of the individual XP practices--especially those that have an impact upon the way we design and write code.
　　 Section 2: Agile Design
　　 The chapters in this section talk about object-oriented software design. The first chapter asks the question, What is Design? It discusses the problem of, and techniques for, managing complexity. Finally, the section culminates with the principles of object-oriented class design.
　　 Section 3: The Payroll Case Study
　　 This is the largest and most complete case study in the book. It describes the object-oriented design and C++ implementation of a simple batch payroll system. The first few chapters in this section describe the design patterns that the case study encounters. The final two chapters contain the full case study.
　　 Section 4: Packaging the Payroll System
　　 This section begins by describing the principles of object-oriented package design. It then goes on to illustrate those principles by incrementally packaging the classes from the previous section.
　　 Section 5: The Weather Station Case Study
　　 This section contains one of the case studies that was originally planned for the Booch book. The Weather Station study describes a company that has made a significant business decision and explains how the Java development team responds to it. As usual, the section begins with a description of the design patterns that will be used and then culminates in the description of the design and implementation.
　　 Section 6: The ETS Case Study
　　 This section contains a description of an actual project that the author participated in. This project has been in production since 1999. It is the automated test system used to deliver and score the registry examination for the National Council of Architectural Registration Boards.
　　 UML Notation Appendices
　　 The first two appendices contains several small case studies that are used to describe the UML notation.
　　 Miscellaneous Appendices
　　How to Use This Book
　　 If You are a Developer...
　　Read the book cover to cover. This book was written primarily for developers, and it contains the information you need to develop software in an agile manner. Reading the book cover to cover introduces practices, then principles, then patterns, and then it provides case studies that tie them all together. Integrating all this knowledge will help you get your projects done.
　　 If You Are a Manager or Business Analyst...
　　Read Section 1, Agile Development. The chapters in this section provide an in-depth discussion of agile principles and practices. They'll take you from requirements to planning to testing, refactoring, and programming. It will give you guidance on how to build teams and manage projects. It will help you get your projects done.
　　 If You Want to Learn UML...
　　First read Appendix A, UML Notation I: The CGI Example. Then read Appendix B, UML Notation II: The STATMUX. Then, read all the chapters in Section 3, The Payroll Case Study. This course of reading will give you a good grounding in both the syntax and use of UlVlL. It will also help you translate between UML and a programming language like Java or C++.
　　 If You Want to Learn Design Patterns...
　　To find a particular pattern, use the "List of Design Patterns" on page xxii to find the pattern you are interested in.
　　 To learn about patterns in general, read Section 2, Agile Design to first learn about design principles, and then read Section 3, The Payroll Case Study; Section 4, Packaging the Payroll System; Section 5, The Weather Station Case Study; and Section 6, The ETS Case Study. These sections define all the patterns and show how to use them in typical situations.
　　 If You Want to Learn about Object-Oriented Design Principles...
　　Read Section 2, Agile Design; Section 3, The Payroll Case Study; and Section 4, Packaging the Payroll System. These chapters will describe the principles of object-oriented design and will show you how to use them.
　　 If You Want to Learn about Agile Development Methods... Read Section 1, Agile Development. This section describes agile development from requirements to planning, testing, refactoring, and programming.
　　 If You Want a Chuckle or Two... Read Appendix C, A Satire of Two Companies.
　　Acknowledgments
　　A heartfelt thanks to:
　　 Lowell Lindstrom, Brian Button, Erik Meade, Mike Hill, Michael Feathers, Jim Newldrk, Micah Martin, Angehque Thouvenin Martin, Susan Rosso, Talisha Jefferson, Ron Jeffries, Kent Beck, Jeff Langr, David Farber, Bob Koss, James Grenning, Lance Welter, Pascal Roy, Martin Fowler, John Goodsen, Alan Apt, Paul Hodgetts, Phil Markgraf, Pete McBreen, H. S. Lahman, Dave Harris, James Kanze, Mark Webster, Chris Biegay, Alan Francis, Fran Daniele, Patrick Lindner, Jake Warde, Amy Todd, Laura Steele, William Pietr, Camille Trentacoste, Vince O'Brien, Gregory Dulles, Lynda Castillo, Craig Larman, Tun Ottinger, Chris Lopez, Phil Goodwill, Charles Toland, Robert Evans, John Roth, Debbie Ufiey, John Brewer, Russ Ruter, David Vydra, Ian Smith, Eric Evans, everyone in the Silicon Valley Patterns group, Pete Brittingham, Graham Perkins, Phlip, and Richard MacDonald.
　　The books reviewers:
　　Pete McBreen / McBreen Consulting Bjame Stroustmp / AT & T Research
　　Stephen J. Mellor / Projtech.com Micah Martin / Object Mentor Inc.
　　Brian Button / Object Mentor Inc. James Grenning / Object Mentor Inc.
　　 A very special thanks to Grady Booch and Paul Becket for allowing me to include chapters that were originally slated for Grady's third edition of Object Oriented Analysis and Design with Applications.
　　 A special thanks to Jack Reeves for graciously allowing me to reproduce his "What is Design?" article.
　　 Another special thanks to Erich Gamma, for writing the foreword to this book. I hope the fonts are better this time Erich!
　　 The wonderful and sometimes dazzling illustrations at the head of each chapter were drawn by Jennifer Kohnke. The decorative illustrations scattered throughout the midst of the chapters are the lovely product of Angela Dawn Martin Brooks, my daughter, and one of the joys of my life.
　　Resources All the source code in this book can be downloaded from www. obi ectmentor, com/PPP.