Agile Principles, Patterns, and Practices in C# / Edition 1

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $38.62
Usually ships in 1-2 business days
(Save 48%)
Other sellers (Hardcover)
  • All (16) from $38.62   
  • New (10) from $49.14   
  • Used (6) from $38.62   

Overview

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.

Read More Show Less

Product Details

  • ISBN-13: 9780131857254
  • Publisher: Prentice Hall
  • Publication date: 8/3/2006
  • Series: Robert C. Martin Series
  • Edition description: 1ST
  • Edition number: 1
  • Pages: 768
  • Sales rank: 364,507
  • Product dimensions: 7.37 (w) x 9.52 (h) x 1.72 (d)

Meet the Author

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.

Read More Show Less

Read an Excerpt

But Bob, you said you’d be done with the book last year.
—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 books—one book every other year while running a consulting company and doing a lot of coding, training, mentoring, speaking, and writing articles, columns, and blogs—not 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 designs in 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 the act of design.Micah’s Introduction

In early 2005, I was on a small development team thatbegan 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, and Practices, by Robert C. Martin, my father, was published in late 2002 and won the 2003 Jolt Award. It is a great book, celebrated by many developers. Unfortunately, it had little impact on the .NET community. Despite the fact that the content of the book is equally relevant to .NET, few .NET programmers have read it.

It is my hope that this .NET edition acts as a bridge between .NET and the rest of the developer community. I hope that programmers will read it and see that there are better ways to build software. I hope that they will begin using better software practices, creating better designs, and raising the bar for quality in .NET applications. I hope that .NET programmers will not be weaker than other programmers. I hope that .NET programmers achieve a new status in the software community such that Java developers are proud to join a .NET team.

Throughout the process of putting this book together, I struggled many times with the concept of my name being on the cover of a .NET book. I questioned whether I wanted my name associated with .NET and all the negative connotations that seemed to come with it. Yet I can no longer deny it. I am a .NET programmer. No! An agile .NET programmer. And I’m proud of it.About This BookA Little History

In the early 1990s I (Bob) wrote Designing Object-Oriented C++ Applications Using the Booch Method. That book was something of a magnum opus for me, and I was very pleased with the result and the sales.

The book you are reading started out as a second edition to Designing, but that’s not how it turned out. Very little remains of the original book in these pages. Little more than three chapters have been carried through, and those have been massively changed. The intent, spirit, and many of the lessons of the book are the same. In the decade since Designing came out, I’ve learned a tremendous amount about software design and development. This book reflects that learning.

What a decade! Designing came out just before the Internet collided with the planet. Since then, the number of acronyms we have to deal with has doubled. We have EJB, RMI, J2EE,

The Booch connection In 1997, I was approached by Grady Booch to help write the third edition of his amazingly successful Object-Oriented Analysis and Design with Applications. I had worked with Grady before on some projects and had been an avid reader and contributor to his various works, including UML. So I accepted with glee and asked my good friend Jim Newkirk to help out with the project.

Over the next two years, Jim and I wrote a number of chapters for the Booch book. Of course, that effort meant that I could not put as much effort into this book as I would have liked, but I felt that the Booch book was worth contributing to. Besides, at the time, this book was simply a second edition of Designing, and my heart wasn’t in it. If I was going to say something, I wanted to say something new and different.

Unfortunately, the Booch book was not to be. It is difficult to find the time to write a book during normal times. During the heady days of the dot-com bubble, it was nearly impossible. Grady got ever busier with Rational and with new ventures such as Catapulse. So the project stalled. Eventually, I asked Grady and Addison-Wesley whether I could have the chapters that Jim and I wrote to include in this book. They graciously agreed. So several of the case study and UML chapters came from that source.

The impact of Extreme Programming In late 1998, XP reared its head and challenged our cherished beliefs about software development. Should we create lots of UML diagrams prior to writing any code? Or should we eschew any kind of diagrams and simply write lots of code? Should we write lots of narrative documents that describe our design? Or should we try to make the code narrative and expressive so that ancillary documents aren’t necessary? Should we program in pairs? Should we write tests before we write production code? What should we do?

This revolution came at an opportune time. During the middle to late 1990s, Object Mentor was helping quite a few companies with OO design and project management issues. We were helping companies get their projects done. As part of that help, we instilled into the teams our own attitudes and practices. Unfortunately, these attitudes and practices were not written down. Rather, they were an oral tradition that was passed from us to our customers.

By 1998, I realized that we needed to write down our process and practices so that we could better articulate them to our customers. So I wrote many articles about process in the C++ Report.1 These articles missed the mark. They were informative and in some cases entertaining, but instead of codifying the practices and attitudes that we used in our projects, they were an unwitting compromise to values that had been imposed on me for decades. It took Kent Beck to show me that.

The Beck connection In late 1998, at the same time 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, such as 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 each other. 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 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 XP, 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 upfront 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 article and books I had written about design, Booch diagrams, and UML diagrams, 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 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, customer onsite: All were 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-driven development (TDD5) sounds innocuous when you first hear it: 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: transformed it for the better.

So by fall of 1999, I 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 XP; my own feeble attempts paled in comparison.

.NET A war is going on among major corporations. These corporations are fighting to gain your allegiance. These corporations believe that if they own the language, they’ll own the programmers and the companies that employ those programmers.

The first volley of this war was Java. Java was the first language created by a major corporpation for the purpose of gaining programmer mindshare. This turned out to be wildly successful. Java has indeed penetrated very deeply into the software community and is largely the de facto standard for modern multilayer IT applications.

One responding volley comes from IBM, which via the Eclipse environment is capturing a large segment of the Java market. The other significant barrage comes from those consumate elaborators at Microsoft who have given us .NET in general and C# in particular.

Amazingly, it is very difficult to differentiate between Java and C#. The languages are semantically equivalent and syntactically so similar that many code snippets are indistinguishable. What Microsoft lacks in technical innovation, it more than makes up for in its remarkable ability to play catch-up and win.

The first edition of this book was written using Java and C++ as the coding language. This book is written using C# and the .NET platform. This should not be viewed as an endorsement. We are not taking sides in this war. Indeed, I think that the war itself will burn itself out when a better language surfaces in the next few years and captures the mindshare of the programmers that the warring corporations have spent so much to secure.

The reason for a .NET version of this book is to reach the .NET audience. Although the principles, patterns, and practices in this book are language agnostic, the case studies are not. Just as .NET programmers are more comfortable reading .NET case studies, Java progarmmers are more comfortable reading Java examples.The Devil Is in the Details

This book contains a lot of .NET code. We hope that you will carefully read that code, since to a large degree, the code is the point of the book. The code is the actualization of what this book has to say.

This book has a repeating pattern: a series of case studies of varying sizes. Some are very small, and some require several chapters to describe. Each case study is preceded by material that is meant to prepare you for it by describing the object-oriented design principles and patterns used in that case study.

The book begins with a discussion on development practices and processes. That discussion is punctuated by a number of small case studies and examples. From there, the book moves on to the topic of design and design principles and then to some design patterns, more design principles that govern packages, and more patterns. All these topics are attended by case studies.

So prepare yourself to read some code and to pore over some UML diagrams. The book you are about to read is very technical, and its lessons, like the devil, are in the details.Organization

This book is organized into four sections and two appendixes.

Section I, Agile Development, describes the concept of agile development. It starts with the Manifesto of the Agile Alliance, provides an overview of Extreme Programming (XP), and then goes to many small case studies that illuminate some of the individual XP practices, especially those that have an impact on the way we design and write code.

Section II, Agile Design, talks about object-oriented software design: what it is, the problem of and techniques for managing complexity, and the principles of object-oriented class design. The section concludes with several chapters that describe a pragmatic subset of UML.

Section III, The Payroll Case Study, 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 chapter is the full case study, the largest and most complete one in the book.

Section IV, Packaging the Payroll System, begins by describing the principles of object-oriented package design and then goes on to illustrate those principles by incrementally packaging the classes from the previous section. The section concludes with chapters that describe the database and UI design of the Payroll application.

Two appendixes follow: Appendix A, A Satire of Two Companies, and Appendix B, Jack Reeves’ article, “What Is Software?”How to Use This Book

If you are a developer, read the book cover to cover. This book was written primarily for developers and contains the information needed to develop software in an agile manner. Reading the book cover to cover introduces practices, and then principles then patterns, and then 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 I, Agile Development. Chapters 1–6 provide an in-depth discussion of agile principles and practices, taking you from requirements to planning to testing, refactoring, and programming. Section I will give you guidance on how to build teams and manage projects. It’ll help you get your projects done.

If you want to learn UML, first read Chapters 13–19. Then read all the chapters in Section III, The Payroll Case Study. This course of reading will give you a good grounding in both the syntax and the use of UML and will also help you translate between UML and C#.

If you want to learn about design patterns, read Section II, Agile Design, to first learn about design principles. Then read Section III, The Payroll Case Study, and Section IV, Packaging the Payroll System. 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 II, Agile Design, Section III, The Payroll Case Study, and Section IV, Packaging the Payroll System. The chapters in those sections describe the principles of object-oriented design and show you how to use them.

If you want to learn about agile development methods, read Section I, Agile Development. This section describes agile development from requirements to planning testing, refactoring, and programming.

If you want a chuckle or two, read Appendix A, A Satire of Two Companies.

1. These articles are available in the publications section of www.objectmentor.com. There are four articles. The first three are entitled “Iterative and Incremental Development” (I, II, III). The last is entitled “C.O.D.E Culled Object Development process.”

2. The website http://c2.com/cgi/wiki. contains a vast number of articles on an immense 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 only 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 Scientific Revolutions, by Thomas S. Kuhn, University of Chicago Press, 1962.

4. If you mention Kuhn twice in paper, you get extra credit.

5. Kent Beck, Test-Driven Development by Example, Addison-Wesley, 2003.

Read More Show Less

Table of Contents

Forewords xix

Preface xxiii

Acknowledgments xxxi

About the Authors xxxiii

Section I: Agile Development 1

Chapter 1: Agile Practices 3

The Agile Alliance 4

Principles 8

Conclusion 10

Bibliography 11

Chapter 2: Overview of Extreme Programming 13

The Practices of Extreme Programming 14

Conclusion 22

Bibliography 22

Chapter 3: Planning 23

Initial Exploration 24

Release Planning 25

Iteration Planning 25

Defining “Done” 26

Task Planning 26

Iterating 27

Tracking 28

Conclusion 29

Bibliography 29

Chapter 4: Testing 31

Test-Driven Development 32

Acceptance Tests 36

Serendipitous Architecture 37

Conclusion 38

Bibliography 39

Chapter 5: Refactoring 41

A Simple Example of Refactoring: Generating Primes 42

Conclusion 53

Bibliography 54

Chapter 6: A Programming Episode 55

The Bowling Game 56

Conclusion 98

Overview of the Rules of Bowling 99

Section II: Agile Design 101

Chapter 7: What Is Agile Design? 103

Design Smells 104

Why Software Rots 107

The Copy Program 108

Conclusion 113

Bibliography 114

Chapter 8: The Single-Responsibility Principle (SRP) 115

Defining a Responsibility 117

Separating Coupled Responsibilities 119

Persistence 119

Conclusion 119

Bibliography 120

Chapter 9: The Open/Closed Principle (OCP) 121

Description of OCP 122

The Shape Application 124

Conclusion 132

Bibliography 133

Chapter 10: The Liskov Substitution Principle (LSP) 135

Violations of LSP 136

Factoring Instead of Deriving 148

Heuristics and Conventions 150

Conclusion 151

Bibliography 151

Chapter 11: The Dependency-Inversion Principle (DIP) 153

Layering 154

A Simple DIP Example 157

The Furnace Example 160

Conclusion 161

Bibliography 162

Chapter 12: The Interface Segregation Principle (ISP) 163

Interface Pollution 163

Separate Clients Mean Separate Interfaces 165

Class Interfaces versus Object Interfaces 166

The ATM User Interface Example 169

Conclusion 174

Bibliography 175

Chapter 13: Overview of UML for C# Programmers 177

Class Diagrams 180

Object Diagrams 182

Collaboration Diagrams 183

State Diagrams 184

Conclusion 185

Bibliography 185

Chapter 14: Working with Diagrams 187

Why Model? 187

Making Effective Use of UML 189

Iterative Refinement 194

When and How to Draw Diagrams 200

Conclusion 202

Chapter 15: State Diagrams 203

The Basics 204

Using FSM Diagrams 208

Conclusion 209

Chapter 16: Object Diagrams 211

A Snapshot in Time 212

Active Objects 213

Conclusion 217

Chapter 17: Use Cases 219

Writing Use Cases 220

Diagramming Use Cases 222

Conclusion 223

Bibliography 223

Chapter 18: Sequence Diagrams 225

The Basics 226

Advanced Concepts 232

Conclusion 241

Chapter 19: Class Diagrams 243

The Basics 244

An Example Class Diagram 247

The Details 249

Conclusion 258

Bibliography 258

Chapter 20: Heuristics and Coffee 259

The Mark IV Special Coffee Maker 260

OOverkill 279

Bibliography 292

Section III: The Payroll Case Study 293

Rudimentary Specification of the Payroll System 294

Exercise 295

Chapter 21: Command and Active Object: Versatility and Multitasking 299

Simple Commands 300

Transactions 302

Undo Method 304

Active Object 305

Conclusion 310

Bibliography 310

Chapter 22: Template Method and Strategy: Inheritance versus Delegation 311

Template Method 312

Strategy 319

Conclusion 324

Bibliography 324

Chapter 23: Facade and Mediator 325

Facade 325

Mediator 327

Conclusion 329

Bibliography 329

Chapter 24: Singleton and Monostate 331

Singleton 332

Monostate 336

Conclusion 343

Bibliography 343

Chapter 25: Null Object 345

Description 345

Conclusion 348

Bibliography 348

Chapter 26: The Payroll Case Study: Iteration 1 349

Rudimentary Specification 350

Analysis by Use Cases 351

Reflection: Finding the Underlying Abstractions 360

Conclusion 363

Bibliography 363

Chapter 27: The Payroll Case Study: Implementation 365

Transactions 366

Main Program 408

The Database 409

Conclusion 411

About This Chapter 411

Bibliography 412

Section IV: Packaging the Payroll System 413

Chapter 28: Principles of Package and Component Design 415

Packages and Components 416

Principles of Component Cohesion: Granularity 417

Principles of Component Coupling: Stability 420

Conclusion 435

Chapter 29: Factory 437

A Dependency Problem 440

Static versus Dynamic Typing 441

Substitutable Factories 442

Using Factories for Test Fixtures 443

Importance of Factories 444

Conclusion 445

Bibliography 445

Chapter 30: The Payroll Case Study: Package Analysis 447

Component Structure and Notation 448

Applying the Common Closure Principle (CCP) 450

Applying the Reuse/Release Equivalence Principle (REP) 452

Coupling and Encapsulation 454

Metrics 455

Applying the Metrics to the Payroll Application 457

The Final Packaging Structure 463

Conclusion 465

Bibliography 465

Chapter 31: Composite 467

Composite Commands 469

Multiplicity or No Multiplicity 470

Conclusion 470

Chapter 32: Observer: Evolving into a Pattern 471

The Digital Clock 472

The Observer Pattern 491

Conclusion 493

Bibliography 494

Chapter 33: Abstract Server, Adapter, and Bridge 495

Abstract Server 496

Adapter 498

Bridge 503

Conclusion 505

Bibliography 506

Chapter 34: Proxy and Gateway: Managing Third-Party APIs 507

Proxy 508

Databases, Middleware, and Other Third-Party Interfaces 526

Table Data Gateway 528

Using Other Patterns with Databases 539

Conclusion 541

Bibliography 541

Chapter 35: Visitor 543

VISITOR 544

Acyclic Visitor 548

Decorator 560

Extension Object 565

Conclusion 576

Bibliography 577

Chapter 36: State 579

Nested Switch/Case Statements 580

Transition Tables 584

The State Pattern 586

Classes of State Machine Application 598

Conclusion 602

Bibliography 602

Chapter 37: The Payroll Case Study: The Database 603

Building the Database 604

A Flaw in the Code Design 605

Adding an Employee 607

Transactions 618

Loading an Employee 623

What Remains? 636

Chapter 38: The Payroll User Interface: Model View Presenter 637

The Interface 639

Implementation 640

Building a Window 650

The Payroll Window 657

The Unveiling 669

Conclusion 670

Bibliography 670

Appendix A: A Satire of Two Companies 671

Rufus Inc.: Project Kickoff 671

Rupert Industries: Project Alpha 671

Appendix B: What Is Software? 687

Index 699

Read More Show Less

Preface

But Bob, you said you’d be done with the book last year.
—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 books—one book every other year while running a consulting company and doing a lot of coding, training, mentoring, speaking, and writing articles, columns, and blogs—not 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 designs in 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 the act of 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, and Practices, by Robert C. Martin, my father, was published in late 2002 and won the 2003 Jolt Award. It is a great book, celebrated by many developers. Unfortunately, it had little impact on the .NET community. Despite the fact that the content of the book is equally relevant to .NET, few .NET programmers have read it.

It is my hope that this .NET edition acts as a bridge between .NET and the rest of the developer community. I hope that programmers will read it and see that there are better ways to build software. I hope that they will begin using better software practices, creating better designs, and raising the bar for quality in .NET applications. I hope that .NET programmers will not be weaker than other programmers. I hope that .NET programmers achieve a new status in the software community such that Java developers are proud to join a .NET team.

Throughout the process of putting this book together, I struggled many times with the concept of my name being on the cover of a .NET book. I questioned whether I wanted my name associated with .NET and all the negative connotations that seemed to come with it. Yet I can no longer deny it. I am a .NET programmer. No! An agile .NET programmer. And I’m proud of it.

About This Book

A Little History

In the early 1990s I (Bob) wrote Designing Object-Oriented C++ Applications Using the Booch Method. That book was something of a magnum opus for me, and I was very pleased with the result and the sales.

The book you are reading started out as a second edition to Designing, but that’s not how it turned out. Very little remains of the original book in these pages. Little more than three chapters have been carried through, and those have been massively changed. The intent, spirit, and many of the lessons of the book are the same. In the decade since Designing came out, I’ve learned a tremendous amount about software design and development. This book reflects that learning.

What a decade! Designing came out just before the Internet collided with the planet. Since then, the number of acronyms we have to deal with has doubled. We have EJB, RMI, J2EE, XML, XSLT, HTML, ASP, JSP, ZOPE, SOAP, C#, and .NET, as well as Design Patterns, Java, Servelets, and Application Servers. Let me tell you, it’s been difficult to keep the chapters of this book current.

The Booch connection In 1997, I was approached by Grady Booch to help write the third edition of his amazingly successful Object-Oriented Analysis and Design with Applications. I had worked with Grady before on some projects and had been an avid reader and contributor to his various works, including UML. So I accepted with glee and asked my good friend Jim Newkirk to help out with the project.

Over the next two years, Jim and I wrote a number of chapters for the Booch book. Of course, that effort meant that I could not put as much effort into this book as I would have liked, but I felt that the Booch book was worth contributing to. Besides, at the time, this book was simply a second edition of Designing, and my heart wasn’t in it. If I was going to say something, I wanted to say something new and different.

Unfortunately, the Booch book was not to be. It is difficult to find the time to write a book during normal times. During the heady days of the dot-com bubble, it was nearly impossible. Grady got ever busier with Rational and with new ventures such as Catapulse. So the project stalled. Eventually, I asked Grady and Addison-Wesley whether I could have the chapters that Jim and I wrote to include in this book. They graciously agreed. So several of the case study and UML chapters came from that source.

The impact of Extreme Programming In late 1998, XP reared its head and challenged our cherished beliefs about software development. Should we create lots of UML diagrams prior to writing any code? Or should we eschew any kind of diagrams and simply write lots of code? Should we write lots of narrative documents that describe our design? Or should we try to make the code narrative and expressive so that ancillary documents aren’t necessary? Should we program in pairs? Should we write tests before we write production code? What should we do?

This revolution came at an opportune time. During the middle to late 1990s, Object Mentor was helping quite a few companies with OO design and project management issues. We were helping companies get their projects done. As part of that help, we instilled into the teams our own attitudes and practices. Unfortunately, these attitudes and practices were not written down. Rather, they were an oral tradition that was passed from us to our customers.

By 1998, I realized that we needed to write down our process and practices so that we could better articulate them to our customers. So I wrote many articles about process in the C++ Report. 1 These articles missed the mark. They were informative and in some cases entertaining, but instead of codifying the practices and attitudes that we used in our projects, they were an unwitting compromise to values that had been imposed on me for decades. It took Kent Beck to show me that.

The Beck connection In late 1998, at the same time 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 wiki 2 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, such as 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 each other. 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 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 XP, 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 upfront 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 article and books I had written about design, Booch diagrams, and UML diagrams, 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 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, customer onsite: All were 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-driven development (TDD5) sounds innocuous when you first hear it: 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: transformed it for the better.

So by fall of 1999, I 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 XP; my own feeble attempts paled in comparison.

.NET A war is going on among major corporations. These corporations are fighting to gain your allegiance. These corporations believe that if they own the language, they’ll own the programmers and the companies that employ those programmers.

The first volley of this war was Java. Java was the first language created by a major corporpation for the purpose of gaining programmer mindshare. This turned out to be wildly successful. Java has indeed penetrated very deeply into the software community and is largely the de facto standard for modern multilayer IT applications.

One responding volley comes from IBM, which via the Eclipse environment is capturing a large segment of the Java market. The other significant barrage comes from those consumate elaborators at Microsoft who have given us .NET in general and C# in particular.

Amazingly, it is very difficult to differentiate between Java and C#. The languages are semantically equivalent and syntactically so similar that many code snippets are indistinguishable. What Microsoft lacks in technical innovation, it more than makes up for in its remarkable ability to play catch-up and win.

The first edition of this book was written using Java and C++ as the coding language. This book is written using C# and the .NET platform. This should not be viewed as an endorsement. We are not taking sides in this war. Indeed, I think that the war itself will burn itself out when a better language surfaces in the next few years and captures the mindshare of the programmers that the warring corporations have spent so much to secure.

The reason for a .NET version of this book is to reach the .NET audience. Although the principles, patterns, and practices in this book are language agnostic, the case studies are not. Just as .NET programmers are more comfortable reading .NET case studies, Java progarmmers are more comfortable reading Java examples.

The Devil Is in the Details

This book contains a lot of .NET code. We hope that you will carefully read that code, since to a large degree, the code is the point of the book. The code is the actualization of what this book has to say.

This book has a repeating pattern: a series of case studies of varying sizes. Some are very small, and some require several chapters to describe. Each case study is preceded by material that is meant to prepare you for it by describing the object-oriented design principles and patterns used in that case study.

The book begins with a discussion on development practices and processes. That discussion is punctuated by a number of small case studies and examples. From there, the book moves on to the topic of design and design principles and then to some design patterns, more design principles that govern packages, and more patterns. All these topics are attended by case studies.

So prepare yourself to read some code and to pore over some UML diagrams. The book you are about to read is very technical, and its lessons, like the devil, are in the details.

Organization

This book is organized into four sections and two appendixes.

Section I, Agile Development, describes the concept of agile development. It starts with the Manifesto of the Agile Alliance, provides an overview of Extreme Programming (XP), and then goes to many small case studies that illuminate some of the individual XP practices, especially those that have an impact on the way we design and write code.

Section II, Agile Design, talks about object-oriented software design: what it is, the problem of and techniques for managing complexity, and the principles of object-oriented class design. The section concludes with several chapters that describe a pragmatic subset of UML.

Section III, The Payroll Case Study, 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 chapter is the full case study, the largest and most complete one in the book.

Section IV, Packaging the Payroll System, begins by describing the principles of object-oriented package design and then goes on to illustrate those principles by incrementally packaging the classes from the previous section. The section concludes with chapters that describe the database and UI design of the Payroll application.

Two appendixes follow: Appendix A, A Satire of Two Companies, and Appendix B, Jack Reeves’ article, “What Is Software?”

How to Use This Book

If you are a developer, read the book cover to cover. This book was written primarily for developers and contains the information needed to develop software in an agile manner. Reading the book cover to cover introduces practices, and then principles then patterns, and then 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 I, Agile Development. Chapters 1–6 provide an in-depth discussion of agile principles and practices, taking you from requirements to planning to testing, refactoring, and programming. Section I will give you guidance on how to build teams and manage projects. It’ll help you get your projects done.

If you want to learn UML, first read Chapters 13–19. Then read all the chapters in Section III, The Payroll Case Study. This course of reading will give you a good grounding in both the syntax and the use of UML and will also help you translate between UML and C#.

If you want to learn about design patterns, read Section II, Agile Design, to first learn about design principles. Then read Section III, The Payroll Case Study, and Section IV, Packaging the Payroll System. 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 II, Agile Design, Section III, The Payroll Case Study, and Section IV, Packaging the Payroll System. The chapters in those sections describe the principles of object-oriented design and show you how to use them.

If you want to learn about agile development methods, read Section I, Agile Development. This section describes agile development from requirements to planning testing, refactoring, and programming.

If you want a chuckle or two, read Appendix A, A Satire of Two Companies.

1. These articles are available in the publications section of www.objectmentor.com. There are four articles. The first three are entitled “Iterative and Incremental Development” (I, II, III). The last is entitled “C.O.D.E Culled Object Development process.”

2. The website http://c2.com/cgi/wiki. contains a vast number of articles on an immense 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 only 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 Scientific Revolutions, by Thomas S. Kuhn, University of Chicago Press, 1962.

4. If you mention Kuhn twice in paper, you get extra credit.

5. Kent Beck, Test-Driven Development by Example, Addison-Wesley, 2003.

Read More Show Less

Customer Reviews

Average Rating 5
( 4 )
Rating Distribution

5 Star

(3)

4 Star

(1)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 4 Customer Reviews
  • Posted January 17, 2009

    Exactly what I was looking for

    One of the few tech books I have read from cover-to-cover. The book explains Agile principles from a reality perspective. I really enjoyed reading someone who understood that getting the code done (and done well) is the most important task versus producing mounds of paperwork.

    1 out of 1 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted August 29, 2006

    recasting of ideas in terms of C#

    In one sense, the book covers no new ground. The Agile principles and patterns discussed here have been well explained for two other languages, Java and C++, especially by Robert Martin in an earlier book. What is offered here is a recasting in terms of C#. Which however has far fewer practitioners than the other languages. Some sections of the book are mostly independent of any language. Take the chapter on state diagrams for documenting finite state machines as one example. Or the other chapters on object diagrams, use cases, sequence diagrams and class diagrams. Some of these do have example code in C#. But inherently, they tend to stand above any language. Some principles are quite useful, albeit perhaps to an advanced programmer. A good example is the chapter on Interface Segregation Principle. Basically, it's about how an interface can grow, if there are several child classes that implement it. The problem is when some classes need routines added to the interface, that other classes do not. So we get a fat interface. This creates a cross-coupling that is unneeded, and a potential source of errors. Something that you should try to minimise, for long term robustness and ease of code maintenance.

    1 out of 1 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 31, 2008

    No text was provided for this review.

  • Anonymous

    Posted September 29, 2009

    No text was provided for this review.

Sort by: Showing all of 4 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)