St. Louis Day of .NET – S.O.L.I.D.
August 24, 2011 Leave a comment
This is part of a series of posts containing my notes from the sessions I attended at the 2011 St. Louis Day of .NET conference.
This series does not attempt to give complete accounts of the information presented in each session; it is just a way to capture the bullet points, notes, and opinions that I recorded while attending the conference. I have previously posted a list of all of the session materials and sample code that I have been able to find online, so if you are looking for a more precise account of a session, try looking there.
My favorite presenter at this year’s conference was Steve Bohlen. He presented at three session; I attended two: “Taming Dependency Chaos with Inversion of Control Containers” and “Refactoring to a SOLID Foundation”. Both were excellent. Following are my notes from the SOLID session.
Single Responsibility Principle
There should never be more than one reason for a class to change. Each class should do one thing.
Open-Closed Principle
Software Entities (classes, modules, functions, etc) should be open for extension, but closed for modification.
Instead of this:
public class Report
{
public void Print()
{
}
}
Use this:
public class Report
{
public virtual void Print()
{
}
}
So that you can do this:
public class Report2 : Report
{
public override void Print()
{
}
}
In this case, the old working code ("Report" class) still works, and we have also added new functionality ("Report2" class).
Liskov Substitution Principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. (Polymorphism; important part highlighted)
Instead of:
public class LetterReport
{
public virtual void Print()
{
}
}
public class TabloidReport : LetterReport
{
public override void Print()
{
}
}
Here, TabloidReport overrides a particular kind of report (LetterReport).
Do this instead:
public abstract class Report
{
public abstract void Print()
{
}
}
public class LetterReport : Report
{
public override void Print()
{
}
}
public class TabloidReport : Report
{
public override void Print()
{
}
}
Now, the base class for the reports is truly generic (it’s not a particular kind of report).
Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they do not use.
Do not build catch-all interfaces like this:
public interface IDataAccess
{
public void SetConnectionString();
public void Connect();
public Data GetReportData();
}
Instead, interfaces should "build upon" other interfaces, as such (interface composition):
public interface IDataAccess
{
public void SetConnectionString();
public void Connect();
}
public interface IReportDataAccess : IDataAccess
{
public Data GetReportData();
}
Now, classes can select the interface that makes the most sense, rather than getting a single interface with everything.
Dependency Inversion Principle
High level modules should not depend on low level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
This is where dependency injection and object composition comes into play. No easy code example to give here.
