Agile Principles, Patterns, and Practices in C#

Robert C. Martin Series

by Robert C. Martin, Micah Martin

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 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.

Genres: Programming, Technical, Technology, Software, Computer Science, Nonfiction, Coding

768 pages, Hardcover

First published July 1, 2006

About the author

Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.

He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.

Reviews

[Gabrielam13 · Rating 4 out of 5]

Design patterns explicate în jurul unor exemple de aplicații, principiile SOLID exhaustiv prezentate, o introducere generală, dar suficientă a UML, clean design la nivel de componente și pachete, toate legate prin lupa principiilor agile sunt părțile constituente ale cărții, pe care le-am savurat și sorbit cu mult mai mult entuziasm decât cele din ”Clean code”. Aceasta se poate datora faptului că, fiind mai amplă, Uncle Bob și-a permis să explice mai îndetaliat toate principiile, dar și faptului că am învățat lucruri noi dincolo de poezia deja repetitivă a codului curat (traducerea sună amuzant în română).

Rămân negreșit fana lui Robert C. Martin, dar aștept cu nerăbdare să descopăr și alți profesioniști în ale programării. Am să mă dedic să îi urmăresc în continuare video-urile, ale căror intenții le înțeleg acum mult mai clar.

[Arjay · Rating 4 out of 5]

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.

About 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.

Excerpt. © Reprinted by permission. All rights reserved.

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 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 cir...

[Vỹ Hồng · Rating 4 out of 5]

This is a great book on software development process and design.

The agile development definition and practices are easy to digest and are common practice nowadays. I particularly enjoy the programming episode between the author and his colleague. It illustrates how software designs are not great from the beginning, but are refined through an iterative process.

Next, the author presents the agile design principles. These are great principles for software development in general, and not limited to agile software development.

In the next section, a payroll case study is presented. This is the driest part of the book, but necessary to illustrate and consolidate the principles and practices outlined in the previous chapters.

The author also presents quite a few OOP design pattern in details, often comparing 2 similar patterns together. They're good reminders if you've known the patterns before, or good introduction if you haven't. My only complain is that they seem scattered and unstructured. If you're like me, you'd often wonder there's a OOP design pattern chapter right in the middle of the "case study" section with no explanation.

The next section about packaging the payroll system is surprisingly educative. This part makes me think about how to structure software components so that they are most maintainable. Something you do every time you add a new class or a new component.

I didn't finish the whole book. I lost interest after the author throws more OOP design patterns at me without explanations the second time. Maybe I'll come back at a later day. But I'm satisfied with what I've learnt for now.

[Qusai Sabri · Rating 4 out of 5]

A great book filled with best practices, not easy to read, as a programmer when I pick a book about programming I expect more technical/coding maybe even small projects from A to Z, this book has more definitions and stories,

I would definitely recommend this book to experienced programmers and specially team leaders as they have the ability to apply those design patterns and force the best practices on the whole team.

This book is not for junior programmers (in my opinion), "Clean Code" by the same author might be a better book to read.

[Sylvain · Rating 3 out of 5]

Covers a (too) vast territory. Long to read. Not everything is interesting...

[Marko Kunic · Rating 5 out of 5]

Besides design pattern, here you will also learn about package designs, different types of UML diagrams, testing and much more. If you have time give it a read, it is worth it.

[Jrwren · Rating 1 out of 5]

This book is not good.

I am writing this in 2020. Perhaps this book, published 2007, is a book from another time. The first chapter ends with a conclusion saying, "Yet our projects fail, or fail to deliver value, at a dismaying rate." While I do recall that being the norm many years ago, I don't recall it in the past 10yrs. Maybe I'm living in an echo chamber of success.

The book opens with chapters titled Agile Practices, Overview of Extreme Programming, Planning, and Testing. The first two are fine. The second two are very problematic. The 5 pages on planning are too short to be of any value to anyone but the complete novice. The Testing chapter introduces Mock Objects without any statement of the problem which they solve. The suggestion to the reader is to always do this. This is terrible advice which doesn't fit with principles of simplicity and you ain't gonna need it that are mentioned later in the book.

The fifth chapter on refactoring is something only an object-oriented only programmer could write. More experienced programmers can see through the gaslighting. The hint is that naming things better is a result of refactoring. I assure you it isn't. Yes, naming things is hard. Put all of the names back the way that they were. Now consider the before and after. Did this refactoring improve the code? No. It didn't. Naming things better improved the code. All of the method extraction made it less cohesive, more difficult to reason about, and more complex. Keep it simple.

Chapter 6 ends section one with a story that is supposed to be an example of everything so far. Meh.

Chapter 7 on agile design rolls out the seven design smells, rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, opacity. All excellent things of which to be aware. But then, the example of the Copy program. IMO this example is too simple to really get the points across. Extracting a reader interface is always a good idea, so I guess it is better than nothing.

Chapter 8 is on infamous SRP and does a reasonable job, but is presented without enough caution for balancing this with the above design smells. The rectangle example is particularly bad because in many cases and in many applications there is absolutely nothing wrong with having that rectangle, or your simple type, be responsible for both modeling itself and displaying itself. Then, it gets worse with the Modem example, because while connecting and the data channel does make sense, why stop there? Why not have reader and writer abstracted? Why not use the same reader interface from the previous chapter and show just how powerful it is to think in terms of readers and writers. Opportunity lost.

Chapter 9 is on OCP and I'll refrain from commenting on the chapter because I don't agree with OCP as a good thing most of the time. It is certainly true for library authors shipping a library to be consumed for other programmers, but in today's monorepo development environments with test coverage, there is no reason to think about this. Make the modification to the behavior that "should be closed", run your tests, and move on. Thinking about this too much wastes time and lowers the value of the resulting products as a result. The example

Chapter 10 is on LSP and it is fine and important, and yet, still with the shapes? Was it unknown in 2007 that shapes are very poor OO examples? Was it thought that anything real would be too complex? Well that is kind of the point of a book like this, right? To show how to deal with that complexity. It fails.

Chapter 11 on dependency inversion aka inversion of control, is probably the most important of these chapters on SOLID and this chapter does a poor job of explaining it, a worse job as an example, and no job and why it is so important.

Chapter 12 on interface... no.. ya know what... i'm done. i can't read anymore. I feel dirty reading this. I feel my home is dirty for having this book in it. I can't wait to drop this in the library return box tomorrow.

[Johnny · Rating 1 out of 5]

One of the biggest disappointments of all the books I read this year. The scope is far too big to cover it in one single book and it therefore lacks the pages to explain the many concepts it introduces. If you know those concepts before, then this is not a problem. But then again, why do you read this book?

The structure is no help either. The section 4 (Packaging the Payroll System) explains what you have to consider for package and component design (as you expect), but then goes on to explain patterns like Visitor, Adapter/Bridge and ends up with the database and Model View Presenter. Such a structure makes it extremely hard to find a specific topic – you more or less need to scan the whole chapter list to find the right place.

The bibliography is for once at the end of every chapter. While I liked that when reading the book for the first time, I hated it as soon as I had to check something. There are 30 places to look up – no problem with an eBook, but unfortunately, I have the print edition…

The book contains an enormous amount of code examples. Unfortunately again, one sees that they are translated from the previous edition of this book that uses Java. This means no C# specific code syntax and therefore not much that justifies the C# in the title. Especially since it ignores the generics, that would made examples like the BubbleSorter much simpler.

I think the topics this book covers are very important. But the way they are covered in this book makes it unnecessary hard to follow along. Instead of this book, you should get a book for each main part and not try to cover all with this one here.

[Fábio Fortkamp · Rating 3 out of 5]

What a great compendium of software development. The authors tell the story of a how a software is developed: from initial discussions, writing tests to aid the the design, and techniques for implementing the design. The agile way is emphasized, with many iterations and little upfront planning. The chapters involving real cases are very valuable.

However, the book's old age affects the reading. The examples in C# are clear enough, but the lack of syntax highlighting makes it very hard to follow. The final appendices are a bit too ironic, which is problematic for a book that's intending to be serious.

I'm a Mechanical Engineer who is working intensily with software development (in Mechanical Engineering); I know how to program and am learning how to do it systematically and in collaboration. This moment is perfect for me to read such a heavy book (not for beginners); if you are also transitioning for a more serious, senior role, take to time to study this book.

[Andrzej · Rating 4 out of 5]

The book is good introduction to agile approach in building software.
First part is about agile planning, extreme programming, testing and refactoring. You can treat this part as good starter to be familiar with those issues.
The rest of the book is focused on agile architecture - design patterns, best practices. It's based on a sample problems authors solves together with reader. There is a lot of code. I mean - really a lot. Most of these code could be replaced with much shorter pseudo-code and I think book will be easier to read.

There are better books describing design patterns, extreme programming, unit testing etc., but you can treat this book as a really god starter, allowing you to understand the basics of mentioned topics.

[Jeremy Morgan · Rating 3 out of 5]

I think this is a pretty decent book. Had I read it 10 years ago I think I would have been really impressed with it.

This book covers a lot of good patterns in it, sprinkled in amongst Agile stuff. I don't think the "fit" was quite made though.

Mid to senior developers may not get as much out of this, because you're likely already familiar with the patterns that are discussed in the book. However, beginners can get a good introduction to the concepts and it's not a complete waste of time.

Some parts were clumsy and the book contradicts itself in places leaving unanswered questions. But it's not a bad book and it contains good information.

[Lee Song · Rating 5 out of 5]

I read few books from uncle bob and I find this very well structured and pleasant to read. It contains knowledge from requirements engineering, planning, solid principles, design patterns and clean architecture. Each of them explained precisely and straight to the point. He also used some simple terms to explain complex concepts precisely.

He oftenly reminds that the advice he given is not absolutely right or wrong. Only use the design where suitable to balance the benefits and complexity.

[Harish Babu · Rating 5 out of 5]

A must read for programers

Well structured, covers important topics with really good examples that can be followed through. Optional challenges to do through out. Don’t skip over the appendixes.

[Eric · Rating 4 out of 5]

This was longer than necessary, including a lot of overlap with other Robert Martin books. This is to be expected, since it's an update to one of his classics, but I do wish the authors had at least dropped some of the discussion of UML.

[LIBBY · Rating 5 out of 5]

Awesome read! Great example of how to go about TDD and examples of design patterns.

[John MacIntyre · Rating 5 out of 5]

I wish I read this sooner. This book really solidified my understanding of SOLID (pun not intended). I also wish I had this as my intro to UML as well; just enough to communicate and take notes.

[Ian · Rating 2 out of 5]

Outdated? Found this hard-going, boring

[Jonn Louie Lim · Rating 5 out of 5]

This was my gateway book to Agile software development as a developer. It's a reference I still regularly revisit from time to time.

[Andrew Slater · Rating 5 out of 5]

Still relevant. A classic.

[Scott · Rating 5 out of 5]

Thicc book, teaches SOLID principles with code examples and case studies.

[Kevin Garner · Rating 4 out of 5]

After finishing this book and thinking about how useful its contents would be for me in the workplace right now in the (almost) final quarter of 2014, I have concluded that this book is a valuable addition to my programmer bookshelf, albeit a mixed bag of good and stale bits. The good aspects of this book will remain useful. However, the stale parts are... well... a little too stale and beg for a new edition, which it seems Uncle Bob doesn't plan to undertake.

The good points:
The book has aspects that will keep this book on the shelf, ready to crack open at a moment's notice: justification for denouncement of excessive documentation and diagramming, encouragement of realistic / sustainable work hours, explanations of design patterns in a (loosely) C# context, explanations of agile PPPs from an angle I had not previously considered, demonstrations on how to produce reliable software development estimates, emphasis on test-first design / development as the foundation on which this book is written, the list could go on (but not much further).

The stale points:
To be fair, any language specific examples will become stale pretty quickly, as technology is always advancing at breakneck speeds. The Author(s) do state early on that they're not telling you "how to do C#!"; rather, they're extending a lofty olive branch to the .NET developer community (thanks....?) and wanting to discuss more language agnostic topics (refer to the good points listed above). A lot of reviewers point out that C# is really just a namesake in this book. Therefore, let's just go ahead and say it: the C# is really stale; there are such amazing things C# can do now that have made the language much more expressive, maintainable, dynamic, and capable. Funnily enough, some of these advancements were called for in Jack Reeves' article included in Appendix B of this book when he was referring to C++'s success at its onset.

In a nutshell:
This book is worth having around. I will refer back to this book often for inspiration on various design patterns. However, I would like a more modern C# publication on implementing these patterns in a way that actually leverages the language and avoids (now) known anti-patterns. It would be grand if someone took the content of this book to the next level with more modern insight.

After having finished Agile C#, I experienced enlightenment in some ways, but at the same time, I need a C# palate cleanser.

[Vinicius Saueia · Rating 5 out of 5]

Excelent book, the exercices/examples are nicely contextualized and the reading flows naturally. The concepts that uncle Bob shows are universal and are not questions of C# only.

[Tom · Rating 5 out of 5]

Great, great book. The first section describing agile development is useful for anyone in the software industry, while the remainder of the book is a must-read for all software developers. The descriptions of patterns and principles are thorough yet clearly explained, supplemented by plenty of code and diagrams. Definitely a book that I'll keep nearby when writing code.

Note: Martin's Agile Software Development: Principles, Patterns, and Practices is very similar to this book. I think Agile Principles, Patterns, and Practices in C# is an updated version of the other book, with more chapters on UML diagrams and all of the example code in C#.

[Emil Petersen · Rating 3 out of 5]

I hate to say it, but this book was almost too practical. I don't know how he did it. It starts out really well with great and sensible ways to work together to make software. Then a flood of C# code enters. Every design principle and pattern is nuked with examples, which should be great but somehow is not. I did not need the specifics in code when I read and so it was a bit of a nuisance after the first 5 principles. It's a bit harsh, but the lay of the land is I ended up liking the book, but not more. Would probably still recommend it - depending on how Code Complete turns out.

[Ueliton Freitas · Rating 5 out of 5]

This book is simply spectacular. In my opinion, with its simple and didactic dialogue focused on OO programming, provides the necessary security to develop any software project. Including project management, requisites analysis, architecture, code representation (UML), testing and TDD. All concepts with examples and source code, and even if the reader does not know C#, learning a new language.

[Joe · Rating 5 out of 5]

If you can buy only one book on agile development in C#, this is the book you should buy. It is well written and a pleasuer to read. It has many examples in C# illlustrating agile development with patterns.

[Jakub Zalas · Rating 5 out of 5]

This is THE book that should be read by any developer who claims to be Agile to confront this view with reality. Amazing overview of test driven development, solid principles of object oriented design, rules of package design and practical design patterns.

[Waylon Martinez · Rating 5 out of 5]

GREAT BOOK!!!! I don't think that I have had more fun reading a programming book.

[Nuwan · Rating 5 out of 5]

A must read for all software engineers

[Minh Ha · Rating 4 out of 5]

Fascinating book. Useful for OO programmers who want to improve their code quality.