Agile Principles, Patterns, And Practices in C#

by Martin, Robert C.; Martin, Micah

• ISBN13: 9780131857254
• ISBN10: 0131857258
• Edition: 1st
• Format: Hardcover
• Copyright: 2006-07-20
• Publisher: PEARSO

Summary

With the award-winning book Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin helped bring Agile principles to tens of thousands of Java and C++ programmers. Now .NET programmers have a definitive guide to agile methods with this completely updated volume from Robert C. Martin and Micah Martin, Agile Principles, Patterns, and Practices in C#.This book presents a series of case studies illustrating the fundamentals of Agile development and Agile design, and moves quickly from UML models to real C# code. The introductory chapters lay out the basics of the agile movement, while the later chapters show proven techniques in action. The book includes many source code examples that are also available for download from the authors' Web site.Readers will come away from this book understanding Agile principles, and the fourteen practices of Extreme Programming Spiking, splitting, velocity, and planning iterations and releases Test-driven development, test-first design, and acceptance testing Refactoring with unit testing Pair programming Agile design and design smells The five types of UML diagrams and how to use them effectively Object-oriented package design and design patterns How to put all of it together for a real-world project Whether you are a C# programmer or a Visual Basic or Java programmer learning C#, a software development manager, or a business analyst, Agile Principles, Patterns, and Practices in C# is the first book you should read to understand agile software and how it applies to programming in the .NET Framework.

Author Biography

Robert C. Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming.

Micah Martin works with Object Mentor as a developer, consultant, and mentor on topics ranging from object-oriented principles and patterns to agile software development practices. Micah is the cocreator and lead developer of the open source FitNesse project. He is also a published author and speaks regularly at conferences.

Table of Contents

Forewords	xix
Preface	xxiii
Acknowledgments	xxxi
About the Authors	xxxiii
Section I: Agile Development	1	(100)
Agile Practices	3	(10)
The Agile Alliance	4	(4)
Individuals and Interactions over Processes and Tools	5	(1)
Working Software over Comprehensive Documentation	6	(1)
Customer Collaboration over Contract Negotiation	6	(1)
Responding to Change over Following a Plan	7	(1)
Principles	8	(2)
Conclusion	10	(1)
Bibliography	11	(2)
Overview of Extreme Programming	13	(10)
The Practices of Extreme Programming	14	(8)
Whole Team	14	(1)
User Stories	14	(1)
Short Cycles	15	(1)
Acceptance Tests	15	(1)
Pair Programming	16	(1)
Test-Driven Development (TDD)	17	(1)
Collective Ownership	17	(1)
Continuous Integration	17	(1)
Sustainable Pace	18	(1)
Open Workspace	18	(1)
The Planning Game	19	(1)
Simple Design	19	(1)
Refactoring	20	(1)
Metaphor	21	(1)
Conclusion	22	(1)
Bibliography	22	(1)
Planning	23	(8)
Initial Exploration	24	(1)
Spiking, Splitting, and Velocity	24	(1)
Release Planning	25	(1)
Iteration Planning	25	(1)
Defining ``Done''	26	(1)
Task Planning	26	(1)
Iterating	27	(1)
Tracking	28	(1)
Conclusion	29	(1)
Bibliography	29	(2)
Testing	31	(10)
Test-Driven Development	32	(4)
Example of Test-First Design	32	(1)
Test Isolation	33	(3)
Serendipitous Decoupling	36	(1)
Acceptance Tests	36	(1)
Serendipitous Architecture	37	(1)
Conclusion	38	(1)
Bibliography	39	(2)
Refactoring	41	(14)
A Simple Example of Refactoring: Generating Primes	42	(11)
Unit Testing	44	(1)
Refactoring	45	(4)
The Final Reread	49	(4)
Conclusion	53	(1)
Bibliography	54	(1)
A Programming Episode	55	(46)
The Bowling Game	56	(42)
Conclusion	98	(1)
Overview of the Rules of Bowling	99	(2)
Section II: Agile Design	101	(192)
What Is Agile Design?	103	(12)
Design Smells	104	(3)
Design Smells---The Odors of Rotting Software	104	(1)
Rigidity	105	(1)
Fragility	105	(1)
Immobility	105	(1)
Viscosity	105	(1)
Needless Complexity	106	(1)
Needless Repetition	106	(1)
Opacity	107	(1)
Why Software Rots	107	(1)
The Copy Program	108	(5)
A Familiar Scenario	108	(3)
Agile Design of the Copy Program	111	(2)
Conclusion	113	(1)
Bibliography	114	(1)
The Single-Responsibility Principle (SRP)	115	(6)
Defining a Responsibility	117	(2)
Separating Coupled Responsibilities	119	(1)
Persistence	119	(1)
Conclusion	119	(1)
Bibliography	120	(1)
The Open/Closed Principle (OCP)	121	(14)
Description of OCP	122	(2)
The Shape Application	124	(8)
Violating OCP	124	(3)
Conforming to OCP	127	(1)
Anticipation and ``Natural'' Structure	128	(1)
Putting the ``Hooks'' In	129	(1)
Using Abstraction to Gain Explicit Closure	130	(1)
Using a Data-Driven Approach to Achieve Closure	131	(1)
Conclusion	132	(1)
Bibliography	133	(2)
The Liskov Substitution Principle (LSP)	135	(18)
Violations of LSP	136	(12)
A Simple Example	136	(2)
A More Subtle Violation	138	(5)
A Real-World Example	143	(5)
Factoring Instead of Deriving	148	(2)
Heuristics and Conventions	150	(1)
Conclusion	151	(1)
Bibliography	151	(2)
The Dependency-Inversion Principle (DIP)	153	(10)
Layering	154	(3)
Ownership Inversion	155	(1)
Dependence on Abstractions	156	(1)
A Simple DIP Example	157	(3)
Finding the Underlying Abstraction	158	(2)
The Furnace Example	160	(1)
Conclusion	161	(1)
Bibliography	162	(1)
The Interface Segregation Principle (ISP)	163	(14)
Interface Pollution	163	(2)
Separate Clients Mean Separate Interfaces	165	(1)
Class Interfaces versus Object Interfaces	166	(3)
Separation Through Delegation	167	(1)
Separation Through Multiple Inheritance	168	(1)
The ATM User Interface Example	169	(5)
Conclusion	174	(1)
Bibliography	175	(2)
Overview of UML for C# Programmers	177	(10)
Class Diagrams	180	(2)
Object Diagrams	182	(1)
Sequence Diagrams	182	(1)
Collaboration Diagrams	183	(1)
State Diagrams	184	(1)
Conclusion	185	(1)
Bibliography	185	(2)
Working with Diagrams	187	(16)
Why Model?	187	(2)
Why Build Models of Software?	188	(1)
Should We Build Comprehensive Designs Before Coding?	188	(1)
Making Effective Use of UML	189	(5)
Communicating with Others	189	(2)
Road Maps	191	(1)
Back-End Documentation	192	(1)
What to Keep and What to Throw Away	192	(2)
Iterative Refinement	194	(6)
Behavior First	194	(2)
Check the Structure	196	(2)
Envisioning the Code	198	(1)
Evolution of Diagrams	199	(1)
When and How to Draw Diagrams	200	(2)
When to Draw Diagrams and When to Stop	200	(1)
Case Tools	201	(1)
But What About Documentation?	202	(1)
Conclusion	202	(1)
State Diagrams	203	(8)
The Basics	204	(4)
Special Events	205	(1)
Superstates	206	(1)
Initial and Final Pseudostates	207	(1)
Using FSM Diagrams	208	(1)
Conclusion	209	(2)
Object Diagrams	211	(8)
A Snapshot in Time	212	(1)
Active Objects	213	(4)
Conclusion	217	(2)
Use Cases	219	(6)
Writing Use Cases	220	(2)
Alternate Courses	221	(1)
What Else?	221	(1)
Diagramming Use Cases	222	(1)
Conclusion	223	(1)
Bibliography	223	(2)
Sequence Diagrams	225	(18)
The Basics	226	(6)
Objects, Lifelines, Messages, and Other Odds and Ends	226	(1)
Creation and Destruction	227	(1)
Simple Loops	228	(1)
Cases and Scenarios	228	(4)
Advanced Concepts	232	(9)
Loops and Conditions	232	(1)
Messages That Take Time	233	(2)
Asynchronous Messages	235	(4)
Multiple Threads	239	(1)
Active Objects	240	(1)
Sending Messages to Interfaces	240	(1)
Conclusion	241	(2)
Class Diagrams	243	(16)
The Basics	244	(3)
Classes	244	(1)
Association	245	(1)
Inheritance	246	(1)
An Example Class Diagram	247	(2)
The Details	249	(9)
Class Stereotypes	249	(1)
Abstract Classes	250	(1)
Properties	251	(1)
Aggregation	252	(1)
Composition	253	(1)
Multiplicity	254	(1)
Association Stereotypes	255	(1)
Nested Classes	256	(1)
Association Classes	256	(1)
Association Qualifiers	257	(1)
Conclusion	258	(1)
Bibliography	258	(1)
Heuristics and Coffee	259	(34)
The Mark IV Special Coffee Maker	260	(19)
Specification	260	(3)
A Common but Hideous Solution	263	(2)
Imaginary Abstraction	265	(1)
An Improved Solution	266	(4)
Implementing the Abstract Model	270	(7)
The Benefits of This Design	277	(2)
OOverkill	279	(13)
Bibliography	292	(1)
Section III: The Payroll Case Study	293	(378)
Rudimentary Specification of the Payroll System	294	(1)
Exercise	295	(4)
Use Case 1: Add New Employee	295	(1)
Use Case 2: Deleting an Employee	295	(1)
Use Case 3: Post a Time Card	296	(1)
Use Case 4: Posting a Sales Receipt	296	(1)
Use Case 5: Posting a Union Service Charge	296	(1)
Use Case 6: Changing Employee Details	296	(1)
Use Case 7: Run the Payroll for Today	297	(2)
Command and Active Object: Versatility and Multitasking	299	(12)
Simple Commands	300	(2)
Transactions	302	(2)
Physical and Temporal Decoupling	304	(1)
Temporal Decoupling	304	(1)
Undo Method	304	(1)
Active Object	305	(5)
Conclusion	310	(1)
Bibliography	310	(1)
Template Method and Strategy: Inheritance versus Delegation	311	(14)
Template Method	312	(7)
Pattern Abuse	315	(1)
Bubble Sort	316	(3)
Strategy	319	(5)
Conclusion	324	(1)
Bibliography	324	(1)
Facade and Mediator	325	(6)
Facade	325	(2)
Mediator	327	(2)
Conclusion	329	(1)
Bibliography	329	(2)
Singleton and Monostate	331	(14)
Singleton	332	(4)
Benefits	334	(1)
Costs	334	(1)
Singleton in Action	334	(2)
Monostate	336	(7)
Benefits	337	(1)
Costs	338	(1)
Monostate in Action	338	(5)
Conclusion	343	(1)
Bibliography	343	(2)
Null Object	345	(4)
Description	345	(3)
Conclusion	348	(1)
Bibliography	348	(1)
The Payroll Case Study: Iteration 1	349	(146)
Rudimentary Specification	350	(1)
Analysis by Use Cases	351	(9)
Adding Employees	352	(1)
Deleting Employees	353	(1)
Posting Time Cards	354	(1)
Posting Sales Receipts	354	(1)
Posting a Union Service Charge	355	(1)
Changing Employee Details	356	(2)
Payday	358	(2)
Reflection: Finding the Underlying Abstractions	360	(3)
Employee Payment	360	(1)
Payment Schedule	360	(2)
Payment Methods	362	(1)
Affiliations	362	(1)
Conclusion	363	(1)
Bibliography	363	(132)
Abstract Server, Adapter, and Bridge	495	(12)
Abstract Server	496	(2)
Adapter	498	(5)
The Class Form of Adapter	498	(1)
The Modem Problem, Adapters, and LSP	499	(4)
Bridge	503	(2)
Conclusion	505	(1)
Bibliography	506	(1)
Proxy and Gateway: Managing Third-Party APIs	507	(36)
Proxy	508	(18)
Implementing Proxy	512	(13)
Summary	525	(1)
Databases, Middleware, and Other Third-Party Interfaces	526	(2)
Table Data Gateway	528	(11)
Testing and In-Memory TDGs	535	(1)
Testing the DB Gateways	536	(3)
Using Other Patterns with Databases	539	(2)
Conclusion	541	(1)
Bibliography	541	(2)
Visitor	543	(36)
Visitor	544	(4)
Acyclic Visitor	548	(12)
Uses of Visitor	552	(8)
Decorator	560	(5)
Extension Object	565	(11)
Conclusion	576	(1)
Bibliography	577	(2)
State	579	(24)
Nested Switch/Case Statements	580	(4)
The Internal Scope State Variable	583	(1)
Testing the Actions	583	(1)
Costs and Benefits	583	(1)
Transition Tables	584	(2)
Using Table Interpretation	585	(1)
Costs and Benefits	586	(1)
The State Pattern	586	(12)
State versus Strategy	589	(1)
Costs and Benefits	590	(1)
The State Machine Compiler (SMC)	591	(2)
Turnstile.cs Generated by SMC, and Other Support Files	593	(5)
Classes of State Machine Application	598	(4)
High-Level Application Policies for GUIs	599	(1)
GUI Interaction Controllers	600	(1)
Distributed Processing	601	(1)
Conclusion	602	(1)
Bibliography	602	(1)
The Payroll Case Study: The Database	603	(34)
Building the Database	604	(1)
A Flaw in the Code Design	605	(2)
Adding an Employee	607	(11)
Transactions	618	(5)
Loading an Employee	623	(13)
What Remains?	636	(1)
The Payroll User Interface: Model View Presenter	637	(34)
The Interface	639	(1)
Implementation	640	(10)
Building a Window	650	(7)
The Payroll Window	657	(12)
The Unveiling	669	(1)
Conclusion	670	(1)
Bibliography	670	(1)
Appendix A: A Satire of Two Companies	671	(16)
Rufus Inc.: Project Kickoff	671	(1)
Rupert Industries: Project Alpha	671	(16)
Appendix B: What Is Software?	687	(12)
Index	699

Excerpts

But Bob, you said you'd be done with the booklastyear. Claudia Frers, UML World, 1999 Bob's Introduction It's been seven years since Claudia's justifiable complaint, but I think I have made up for it. Publishing three booksone book every other year while running a consulting company and doing a lot of coding, training, mentoring, speaking, and writing articles, columns, and blogsnot to mention raising a family and enjoying a grandfamily can be quite a challenge. But I love it. Agile development is the ability to develop software quickly, in the face of rapidly changing requirements. In order to achieve this agility, we need to use practices that provide the necessary discipline and feedback. We need to employ design principles that keep our software flexible and maintainable, and we need to know the design patterns that have been shown to balance those principles for specific problems. This book is an attempt to knit all three of these concepts together into a functioning whole. This book describes those principles, patterns, and practices and then demonstrates how they are applied by walking through dozens of different case studies. More important, the case studies are not presented as complete works. Rather, they are designsin progress.You will see the designers make mistakes and observe how they identify them as mistakes and eventually correct them. You will see the designers puzzle over conundrums and worry over ambiguities and trade-offs. You will see theactof design. Micah's Introduction In early 2005, I was on a small development team that began work on a .NET application to be written in C#. Using agile development practices was mandatory, which is one of the reasons I was involved. Although I had used C# before, most of my programming experience was in Java and C++. I didn't think that working in .NET would make much difference; in the end it didn't. Two months into the project, we made our first release. It was a partial release containing only a fraction of all the intended features, but it was enough to be usable. And use it they did. After only two months, the organization was reaping the benefits of our development. Management was so thrilled that it asked to hire more people so we could start more projects. Having participated in the agile community for years, I knew a good many agile developers who could help us. I called them all and asked them to join us. Not one of my agile colleagues ended up joining our team. Why not? Perhaps the most overwhelming reason was the fact that we were developing in .NET. Almost all agile developers have a background in Java, C++, or Smalltalk. But agile .NET programmers are almost unheard of. Perhaps my friends didn't take me seriously when I said we were doing agile software development with .NET, or maybe they were avoiding association with .NET. This was a significant problem. It was not the first evidence I'd seen of this problem, either. Teaching week-long courses on various software topics allows me to meet a wide cross-section of developers from around the world. Many of the students I've instructed were .NET programmers, and many were Java or C++ programmers. There's no gentle way to put this: In my experience, .NET programmers are often weaker than Java and C++ programmers. Obviously, this is not always the case. However, after observing it over and over in my classes, I can come to no other conclusion: .NET programmers tend to be weaker in agile software practices, design patterns, design principles, and so on. Often in my classes, the .NET programmers had never heard of these fundamental concepts.This has to change. The first edition of this book,Agile Software Development: Principles, Patterns, a