Pro .NET 2.0 Code And Design Standards In CSharp (2006) [eng]

x ■C O N T E N T S

Thinking and Talking in a Pattern Language . . . . . . . . . . . . . . . . . . . . . . . 173

Pattern Language in Computer Science . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

■CHAPTER 10 Creational Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Abstract Factory Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Factory Method Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Singleton Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

■CHAPTER 11 Structural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Proxy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Proxy Pattern Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Adapter Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Composite Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Facade Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

■CHAPTER 12 Behavioral Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chain of Responsibility Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Observer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Strategy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Template Method Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

PART 4 ■ ■ ■ References

■APPENDIX A Environment Variables and Remote Proxy Example . . . . 257

Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Remote-Proxy Pattern Example: Using the Command Line . . . . . . . . . . 261

■LIST OF STANDARDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Code Policy Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Code Structure Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Code Development Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Code Documentation Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Design Policy Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

■C O N T E N T S xi

Design Structure Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Design Development Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Design Documentation Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Pattern Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Creational Pattern Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Structural Pattern Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Behavioral Pattern Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

■GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

About the Author

■MARK HORNER is Principal Enterprise Architect and .NET Application consultant with Torville Software. He is a 25-year veteran of the industry and has worked with a host of blue-chip organizations, including Citibank, NRMA Insurance, ANZ Banking Group, Unilever, HewlettPackard, British Aerospace, and CPA Australia. You can contact him at [e-mail].

xiii

About the Technical Reviewer

■JON REID is the Vice-President of Engineering for Indigo Biosystems (www.indigobio.com), an independent software vendor providing data management solutions for the life sciences, where he writes tools using C#, Java, and XML. Jon was editor of the Object Query Language and C++ Working Groups of the Object Data Management Group (ODMG) and has coauthored many books on .NET and C#, including

Beginning C# Databases: From Novice to Professional (Apress, 2004) and Pro Visual Studio .NET (Apress, 2004). Jon would like to thank his family, his colleagues, and the great group at Apress for supporting his writing efforts.

xv

Acknowledgments

This book is a composite of teamwork, and there are so many contributions to acknowledge. The book started off as a simple idea: I thought that the C# community needed “A catalog of standard practices.” The idea quickly got the backing of Gary Cornell, Kylie Johnston, Ewan Buckingham, and Dominic Shakeshaft; and veteran author Donald Xie shared his views in the preliminary stages. The book was guided through the twists and turns of development by the forever-alert “Becks” (Beckie Brand). Ewan Buckingham, as lead editor, expertly nurtured the content of the book. The experience of fellow Apress author Jon Reid, in the role of technical reviewer, was invaluable, while Angela Buckley of Freelance Editorial Services and Ami Knox smoothed many of the rough edges. Thanks also to the rest of the team, including Grace Wong, Nicole LeClerc, Kari Brooks-Copony, Ellie Fountain, Molly Sharp, Linda Seifert, Toma Mulligan, Kinetic Publishing, Van Winkle Design Group, Kurt Krames, Tom Debolski, and Matthew Mason for the photograph. Finally, a special thanks to the design team at Microsoft for the C# language: Anders Hejlsberg, Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, Peter Hallam, Shon Katzenberger, Todd Proebsting, Anson Horton, Don Syme, and Andrew Kennedy.

xvii

Introduction

This is not a book that tells you what you should or shouldn’t do! So, in the immortal words of Douglas Adams (www.douglasadams.com): “Don’t Panic!” Yes, it is a book on standards, but the standards are not presented as a set of rules; rather, they are presented and explained as

a catalog of standard practices that are commonplace in the development community. My job is to bring them to your attention, and it’s your choice whether you use them.

Generally, there are two categories of standards: internal and external. Internal standards are those standards that are in-house standards, whereas external standards are standards that are used between organizations to standardize a selection of industry practices (e.g., IEEE-1016 documentation for software design or IEEE-830 software requirements standard).

There are two leading organizations that develop external standards relevant to architects and developers: IEEE and W3C. Whereas IEEE focuses on standards for a wide range of industries, including information technology, W3C has a sharper focus on Internet technology.

■Note IEEE-SA is an acronym for Institute of Electrical and Electronics Engineers Standards Association. The association is the leading developer of international standards for a wide range of industries: information technology, telecommunication, biomedical and health care, and power and energy, for example. It offers a subscription service to access the standards; you can check out their website at www.ieee.org. W3C is an acronym for the World Wide Web Consortium, which develops products and standards on Internet technology (e.g., HTML, XML, and Encryption). It offers a nonsubscription service to access the standards; you can check out their website at www.w3c.org.

This book is about internal standards only. Its role is to present to you a catalog of standards that are understood to be in the public domain and free to use and specialize for your situation. Standards have been categorized as code, design, and patterns. Code standards discuss policy, structure, development, and documentation of code. Design standards discuss code design from a policy, structure, development, and documentation perspective. Finally, pattern standards discuss a subset of the design patterns catalogued by Drs. Gamma, Helm, Johnson, and Vlissides (known as the “Gang of Four,” or “GoF”). It also acknowledges the contribution to the pattern community by Professor Alexander, Professor Reenskaug, and GoF.

The Motivation: Why Do We Need Standards?

There are three key reasons to use standards: success, uniformity, and transparency. First, in an industry as volatile as information technology, if a given code or design practice lasts for a few seasons, then it tends to do so because it is successful. However, that success does not mean

xix