SOLID principles or none SOLID

Question

I am continuing the development of an ASP.NET application (web form based) where the previous developer did not follow principles of good Object Oriented design i.e. SOLID (http://www.remondo.net/solid-principles-csharp-interface-segregation/). I have read posts like this: Long-held, incorrect programming assumptions.

The problem is that a lot of the classes have low cohesion and are highly coupled and a lot of the classes do not have a single responsibility (they have many). My specific question is: should I start following the SOLID principles or just continue developing by tweeking and adding more to the classes? I have always tried to follow principles like SOLID in the past, but the application I am talking about is very large and complex. I am the only developer working on this project.

A complete rewrite is out of the question at the moment but will be possible one day.

Update 15/07/2012 So far I have discovered that SOLID is a design principle and GRASP is a design pattern, which is perhaps more suitable to MVC rather than a Page Controller type application. Mock objects are also perhaps more suited to MVC according to this link: http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview. Based on the response so far it is always good practice to follow SOLID principles. However, the answers so far do not recommend design patterns for form based apps.

Answer 1

Try refactoring bit by bit.

If you are working on a module, try adding a few interfaces here and there ;-) as you go. Any new code that you write should be SOLID. Try encapsulating old code as much as possible, put old crap behind a facade. You don't have to rewrite it right now, maybe never. As long as you can encapsulate old code behind a facade and write unit tests for the facade you should feel a lot better.

Example: So lets say you have a collection of classes that implement some piece of functionality, ie. invoice processing. Right now I imagine those classes are used in many places and there is a lot of duplication going on. The code for calculating total invoice amount is copied on every page that displays it. What I would do in that case is to create an Invoice service which will expose methods for getting an invoice, adding new lines, calculating total amount, etc. You can than put the code that you have in this service without much refactoring, you will keep the same db schema and so on. But from now on your pages will interact only with IInvoiceService interface and you can mock it nicely. It is a bit of 'swiping dust under the carpet' but at least you can stop the crap spreading even further. Next time you need to do something in the invoicing module (fix a bug, implement new feature) you clean the existing code a bit. Over time the amount of dust under the carpet gets smaller and smaller. You just need to stick to your guns and make sure that the service interface stays nice and clean.

You may need to make some more system-wide changes, like introducing DI framework, but try keeping the changes to minimal. Usually when you start going to far you can easily find yourself rewriting everything, and you don't want that.

Make small changes, commit often.