How to implement SOLID principles into an existing project

by

Single Responsibility Principle – A class should have only one reason to change. If you have a monolithic class, then it probably has more than one reason to change. Simply define your one reason to change, and be as granular as reasonable. I would suggest to start “large”. Refactor one third of the code out into another class. Once you have that, then start over with your new class. Going straight from one class to 20 is too daunting.

Open/Closed Principle – A class should be open for extension, but closed for change. Where reasonable, mark your members and methods as virtual or abstract. Each item should be relatively small in nature, and give you some base functionality or definition of behavior. However, if you need to change the functionality later, you will be able to add code, rather than change code to introduce new/different functionality.

Liskov Substitution Principle – A class should be substitutable for its base class. The key here, in my opinion, is do to inheritance correctly. If you have a huge case statement, or two pages of if statements that check the derived type of the object, then your violating this principle and need to rethink your approach.

Interface Segregation Principle – In my mind, this principle closely resembles the Single Responsibility principle. It just applies specifically to a high level (or mature) class/interface. One way to use this principle in a large class is to make your class implement an empty interface. Next, change all of the types that use your class to be the type of the interface. This will break your code. However, it will point out exactly how you are consuming your class. If you have three instances that each use their own subset of methods and properties, then you now know that you need three different interfaces. Each interface represents a collective set of functionality, and one reason to change.

Dependency Inversion Principle – The parent / child allegory made me understand this. Think of a parent class. It defines behavior, but isn’t concerned with the dirty details. It’s dependable. A child class, however, is all about the details, and can’t be depended upon because it changes often. You always want to depend upon the parent, responsible classes, and never the other way around. If you have a parent class depending upon a child class, you’ll get unexpected behavior when you change something. In my mind, this is the same mindset of SOA. A service contract defines inputs, outputs, and behavior, with no details.

Of course, my opinions and understandings may be incomplete or wrong. I would suggest learning from people who have mastered these principles, like Uncle Bob. A good starting point for me was his book, Agile Principles, Patterns, and Practices in C#. Another good resource was Uncle Bob on Hanselminutes.

Of course, as Joel and Jeff pointed out, these are principles, not rules. They are to be tools to help guide you, not the law of the land.

EDIT:

I just found these SOLID screencasts which look really interesting. Each one is approximately 10-15 minutes long.

More Related Contents:

  1. DDD Approach to Access External Information
  2. C# Object Pooling Pattern implementation
  3. C# producer/consumer
  4. Unity singleton manager classes
  5. Thread Safe C# Singleton Pattern
  6. Large Switch statements: Bad OOP?
  7. Instantiate an object with a runtime-determined type
  8. Singleton by Jon Skeet clarification
  9. What’s a good threadsafe singleton generic template pattern in C#
  10. lock keyword in C#
  11. Refactoring code to avoid anti-pattern
  12. When should I choose inheritance over an interface when designing C# class libraries? [closed]
  13. Design pattern for handling multiple message types
  14. Merge multiple Lists into one List with LINQ
  15. What is difference between MVC, MVP & MVVM design pattern in terms of coding c#
  16. Learning Single Responsibility Principle with C#
  17. Multiple Aggregates / Repositories in one Transaction
  18. MVVM show new window from VM when seperated projects
  19. Singleton httpclient vs creating new httpclient request
  20. getting db connection through singleton class
  21. Using a Strategy and Factory Pattern with Dependency Injection
  22. Entity Framework Specification Pattern Implementation
  23. Can you explain Liskov Substitution Principle with a good C# example? [closed]
  24. Factory pattern in C#: How to ensure an object instance can only be created by a factory class?
  25. How would you implement a “trait” design-pattern in C#?
  26. Need an ASP.NET MVC long running process with user feedback
  27. View Models and dependency injection
  28. Best practices for multi-form applications to show and hide forms? [closed]
  29. Timeout pattern on task-based asynchronous method in C#
  30. Why doesn’t generic ICollection implement IReadOnlyCollection in .NET 4.5?

Leave a Comment