On January 22, 2009, I will be giving a presentation at the Southeast Valley .Net Users Group on Building Flexible Applications with a Dependency Injection Container. The presentation will cover the common uses of a dependency injection container and show how they can help create applications that are more testable, maintainable and resilient to change. The presentation will also cover some common development principles like SRP, LSP, OCP and ISP.

Scheduled Demonstrations:

• Using Castle Windsor and the MVP pattern in an Asp.Net website
• Creating an extensible and configurable pipeline processor using Ninject
• Decorator chains and aspect oriented programming using Unity from Microsoft

It’s the new year and hopefully you have made a New Year’s resolution to get involved with the community. So, come out, have some pizza, and learn something new. My company Blue Cognition LLC is sponsoring the presentation, so don't worry about pushy recruiters.

This series of articles will identify and describe the more common design principle of Object Orientated Application Development. It is with the understanding and judicious use of these principle that you will be able to developing more flexible, maintainable and extensible software systems, while avoiding common costly mistakes.

Definition: Principles

• an accepted or professed rule of action or conduct: a person of good moral principles.
• a fundamental, primary, or general law or truth from which others are derived: the principles of modern physics.
• principles, a personal or specific basis of conduct or management: to adhere to ones principles.
• guiding sense of the requirements and obligations of right conduct: a person of principle.
• an adopted rule or method for application in action: a working principle for general use.

Design principles are not laws but guides and should be treated as such. The understanding of these principles and when to use them is as equally important as to when not to use them. Over use of one or more design principles will create software with needles complexity and be un-maintainable.

Class Design

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• The Law Of Demeter (LOD)
• Dependency Inversion Principle (DIP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Separation of Concerns (SOC)
• Principle of Least Surprise
• Hollywood Principles
• Don’t Repeat Yourself (DRY)

Package Design

• Reuse/Release Equivalency Principle (REP)
• Common Reuse Principle (CRP)
• Common Closure Principle (CCP)
• Acyclic Dependencies Principle (ADP)
• Stable Dependencies Principle (SDP)
• Stable Abstractions Principle (SAP)

Conclusion

Design Principles are tools and techniques that every developer should learn and master. With the use of these principles, better, faster, extensible and more maintainable software and computer systems can be constructed. On the other hand, the use of these design principles will not guarantee success in software development, but it does give you an advantage. This list of principles is not a complete list and will be updated when other principles come to my attention.

Links

For further reading:

Agile Principles, Patterns, and Practices in C#

Head First Object Orientated Analysis and Design

	Title:	Practices of an Agile Developer: Working in the Real World
	Auther:	Venkat Subramaniam and Andy Hunt
	Publisher:	Pragmatic Programmers
	ISBN:	097451408X
	Copyright:	2006
	Rating:	Great

The pragmatic programmers have done it again. They have written a very usable and accessible book to help developers be better developers. With chapter topics ranging from Agile Feedback to Agile Collaboration, the authors give readers 45 solid practices that they can start using immediately to make them better at their chosen craft.

List of Practices

• Work for Outcome
• Quick Fixes Become Quicksand
• Criticize Ideas, Not People
• Damn the Torpedoes, Go Ahead
• Keep Up with Change
• Invest in Your Team
• Know When to Unlearn
• Question Until You Understand
• Feel the Rhythm
• Let Customers Make Decisions
• Let Design Guide, Not Dictate
• Justify Technology Use
• Keep It Releasable
• Integrate Early, Integrate Often
• Automate Deployment Early
• Get Frequent Feedback Using Demos
• Use Short Iterations, Release in Increments
• Fixed Prices Are Broken Promises
• Put Angels on Your Shoulders
• Use It Before You Build It
• Different Makes a Difference
• Automate Acceptance Testing
• Measure Real Progress
• Listen to Users
• Program Intently and Expressively
• Communicate in Code
• Actively Evaluate Trade-Offs
• Code in Increments
• Keep It Simple
• Write Cohesive Code
• Tell, Don’t Ask
• Substitute by Contract
• Keep a Solutions Log
• Warnings Are Really Errors
• Attack Problems in Isolation
• Report All Exceptions
• Provide Useful Error Messges
• Schedule Regular Face Time
• Architects Must Write Code
• Practice Collective Ownership
• Be a Mentor
• Allow People to Figure It Out
• Share Code Only When Ready
• Review Code
• Keep Others Informed

I found that the book's angel and devil characters dancing on the developers shoulders help convey the importance of the practices like Work for Outcome and Listen to Users. Each practice starts out with a comment made by one of the devils which can represents you on one of your lazy days when you are not thinking in an agile way. These devil's comments describes the practices that should be avoided like in the practice Automate Deployment Early.

“It’s OK to install your product manually, especially to QA. You don’t have to do it all that often, and they are pretty good about copying all the right files.” The Devil

Every practice is then followed by practical advice on how to avoid or mitigate the source of the problem that the practice is trying to solve. It is in these pages that you will find the important information on the Why and the How of each agile practice.

The authors talk at the end of the book about how they have introduced these agile practices to developers on exsisting failing projects to try and turn them around. It is this advice that I find very usable to me in my role as a consultant. They do advise that adding too many new practices to an unstable or failing development projects would not be advisable. They first advise us to stablize the development effort before introducing new practices.

Conclusion

I have been a fan of the great work from the pragmatic programmers and this book does not disappoint. The authors have skillfully boiled down their knowledge of agile practices into readable, usable and actionable practices that can be applied by developers and managers alike today.