The SOLID Design Principles in C# ASP.NET
Concepts
In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The Law of Demeter
is known as the Least Knowledge Principle (LKP), which is also an important design guideline for developing software applications.
Single Responsibility Principle
A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using static System.Console;
namespace DotNetDesignPatternDemos.SOLID.SRP
{
// just stores a couple of journal entries and ways of
// working with them
public class Journal
{
private readonly List<string> entries = new List<string>();
private static int count = 0;
public int AddEntry(string text)
{
entries.Add($"{++count}: {text}");
return count; // memento pattern!
}
public void RemoveEntry(int index)
{
entries.RemoveAt(index);
}
public override string ToString()
{
return string.Join(Environment.NewLine, entries);
}
// breaks single responsibility principle
public void Save(string filename, bool overwrite = false)
{
File.WriteAllText(filename, ToString());
}
public void Load(string filename)
{
}
public void Load(Uri uri)
{
}
}
// handles the responsibility of persisting objects
public class Persistence
{
public void SaveToFile(Journal journal, string filename, bool overwrite = false)
{
if (overwrite || !File.Exists(filename))
File.WriteAllText(filename, journal.ToString());
}
}
public class Demo
{
static void Main(string[] args)
{
var j = new Journal();
j.AddEntry("I cried today.");
j.AddEntry("I ate a bug.");
WriteLine(j);
var p = new Persistence();
var filename = @"c:\temp\journal.txt";
p.SaveToFile(j, filename);
Process.Start(filename);
}
}
}
Open Closed Principle
software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
using System;
using System.Collections.Generic;
using static System.Console;
namespace DotNetDesignPatternDemos.SOLID.OCP
{
public enum Color
{
Red, Green, Blue
}
public enum Size
{
Small, Medium, Large, Yuge
}
public class Product
{
public string Name;
public Color Color;
public Size Size;
public Product(string name, Color color, Size size)
{
Name = name ?? throw new ArgumentNullException(paramName: nameof(name));
Color = color;
Size = size;
}
}
public class ProductFilter
{
// let's suppose we don't want ad-hoc queries on products
public IEnumerable<Product> FilterByColor(IEnumerable<Product> products, Color color)
{
foreach (var p in products)
if (p.Color == color)
yield return p;
}
public static IEnumerable<Product> FilterBySize(IEnumerable<Product> products, Size size)
{
foreach (var p in products)
if (p.Size == size)
yield return p;
}
public static IEnumerable<Product> FilterBySizeAndColor(IEnumerable<Product> products, Size size, Color color)
{
foreach (var p in products)
if (p.Size == size && p.Color == color)
yield return p;
} // state space explosion
// 3 criteria = 7 methods
// OCP = open for extension but closed for modification
}
// we introduce two new interfaces that are open for extension
public interface ISpecification<T>
{
bool IsSatisfied(Product p);
}
public interface IFilter<T>
{
IEnumerable<T> Filter(IEnumerable<T> items, ISpecification<T> spec);
}
public class ColorSpecification : ISpecification<Product>
{
private Color color;
public ColorSpecification(Color color)
{
this.color = color;
}
public bool IsSatisfied(Product p)
{
return p.Color == color;
}
}
public class SizeSpecification : ISpecification<Product>
{
private Size size;
public SizeSpecification(Size size)
{
this.size = size;
}
public bool IsSatisfied(Product p)
{
return p.Size == size;
}
}
// combinator
public class AndSpecification<T> : ISpecification<T>
{
private ISpecification<T> first, second;
public AndSpecification(ISpecification<T> first, ISpecification<T> second)
{
this.first = first ?? throw new ArgumentNullException(paramName: nameof(first));
this.second = second ?? throw new ArgumentNullException(paramName: nameof(second));
}
public bool IsSatisfied(Product p)
{
return first.IsSatisfied(p) && second.IsSatisfied(p);
}
}
public class BetterFilter : IFilter<Product>
{
public IEnumerable<Product> Filter(IEnumerable<Product> items, ISpecification<Product> spec)
{
foreach (var i in items)
if (spec.IsSatisfied(i))
yield return i;
}
}
public class Demo
{
static void Main(string[] args)
{
var apple = new Product("Apple", Color.Green, Size.Small);
var tree = new Product("Tree", Color.Green, Size.Large);
var house = new Product("House", Color.Blue, Size.Large);
Product[] products = {apple, tree, house};
var pf = new ProductFilter();
WriteLine("Green products (old):");
foreach (var p in pf.FilterByColor(products, Color.Green))
WriteLine($" - {p.Name} is green");
// ^^ BEFORE
// vv AFTER
var bf = new BetterFilter();
WriteLine("Green products (new):");
foreach (var p in bf.Filter(products, new ColorSpecification(Color.Green)))
WriteLine($" - {p.Name} is green");
WriteLine("Large products");
foreach (var p in bf.Filter(products, new SizeSpecification(Size.Large)))
WriteLine($" - {p.Name} is large");
WriteLine("Large blue items");
foreach (var p in bf.Filter(products,
new AndSpecification<Product>(new ColorSpecification(Color.Blue), new SizeSpecification(Size.Large)))
)
{
WriteLine($" - {p.Name} is big and blue");
}
}
}
}
Liskov Substitution Principle
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
using static System.Console;
namespace DotNetDesignPatternDemos.SOLID.LiskovSubstitutionPrinciple
{
// using a classic example
public class Rectangle
{
//public int Width { get; set; }
//public int Height { get; set; }
public virtual int Width { get; set; }
public virtual int Height { get; set; }
public Rectangle()
{
}
public Rectangle(int width, int height)
{
Width = width;
Height = height;
}
public override string ToString()
{
return $"{nameof(Width)}: {Width}, {nameof(Height)}: {Height}";
}
}
public class Square : Rectangle
{
//public new int Width
//{
// set { base.Width = base.Height = value; }
//}
//public new int Height
//{
// set { base.Width = base.Height = value; }
//}
public override int Width // nasty side effects
{
set { base.Width = base.Height = value; }
}
public override int Height
{
set { base.Width = base.Height = value; }
}
}
public class Demo
{
static public int Area(Rectangle r) => r.Width * r.Height;
static void Main(string[] args)
{
Rectangle rc = new Rectangle(2,3);
WriteLine($"{rc} has area {Area(rc)}");
// should be able to substitute a base type for a subtype
/*Square*/ Rectangle sq = new Square();
sq.Width = 4;
WriteLine($"{sq} has area {Area(sq)}");
}
}
}
Interface Segregation Principle
Many client-specific interfaces are better than one general-purpose interface. Clients should not be forced to depend upon interfaces that they do not use.
using System;
namespace DotNetDesignPatternDemos.SOLID.InterfaceSegregationPrinciple
{
public class Document
{
}
public interface IMachine
{
void Print(Document d);
void Fax(Document d);
void Scan(Document d);
}
// ok if you need a multifunction machine
public class MultiFunctionPrinter : IMachine
{
public void Print(Document d)
{
//
}
public void Fax(Document d)
{
//
}
public void Scan(Document d)
{
//
}
}
public class OldFashionedPrinter : IMachine
{
public void Print(Document d)
{
// yep
}
public void Fax(Document d)
{
throw new System.NotImplementedException();
}
public void Scan(Document d)
{
throw new System.NotImplementedException();
}
}
public interface IPrinter
{
void Print(Document d);
}
public interface IScanner
{
void Scan(Document d);
}
public class Printer : IPrinter
{
public void Print(Document d)
{
}
}
public class Photocopier : IPrinter, IScanner
{
public void Print(Document d)
{
throw new System.NotImplementedException();
}
public void Scan(Document d)
{
throw new System.NotImplementedException();
}
}
public interface IMultiFunctionDevice : IPrinter, IScanner //
{
}
public struct MultiFunctionMachine : IMultiFunctionDevice
{
// compose this out of several modules
private IPrinter printer;
private IScanner scanner;
public MultiFunctionMachine(IPrinter printer, IScanner scanner)
{
if (printer == null)
{
throw new ArgumentNullException(paramName: nameof(printer));
}
if (scanner == null)
{
throw new ArgumentNullException(paramName: nameof(scanner));
}
this.printer = printer;
this.scanner = scanner;
}
public void Print(Document d)
{
printer.Print(d);
}
public void Scan(Document d)
{
scanner.Scan(d);
}
}
}
Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
using System;
using System.Collections.Generic;
using System.Linq;
using static System.Console;
namespace DotNetDesignPatternDemos.SOLID.DependencyInversionPrinciple
{
// hl modules should not depend on low-level; both should depend on abstractions
// abstractions should not depend on details; details should depend on abstractions
public enum Relationship
{
Parent,
Child,
Sibling
}
public class Person
{
public string Name;
// public DateTime DateOfBirth;
}
public interface IRelationshipBrowser
{
IEnumerable<Person> FindAllChildrenOf(string name);
}
public class Relationships : IRelationshipBrowser // low-level
{
private List<(Person,Relationship,Person)> relations
= new List<(Person, Relationship, Person)>();
public void AddParentAndChild(Person parent, Person child)
{
relations.Add((parent, Relationship.Parent, child));
relations.Add((child, Relationship.Child, parent));
}
public List<(Person, Relationship, Person)> Relations => relations;
public IEnumerable<Person> FindAllChildrenOf(string name)
{
return relations
.Where(x => x.Item1.Name == name
&& x.Item2 == Relationship.Parent).Select(r => r.Item3);
}
}
public class Research
{
public Research(Relationships relationships)
{
// high-level: find all of john's children
//var relations = relationships.Relations;
//foreach (var r in relations
// .Where(x => x.Item1.Name == "John"
// && x.Item2 == Relationship.Parent))
//{
// WriteLine($"John has a child called {r.Item3.Name}");
//}
}
public Research(IRelationshipBrowser browser) {
foreach (var p in browser.FindAllChildrenOf("John"))
{
WriteLine($"John has a child called {p.Name}");
}
}
static void Main(string[] args)
{
var parent = new Person {Name = "John"};
var child1 = new Person {Name = "Chris"};
var child2 = new Person {Name = "Matt"};
// low-level module
var relationships = new Relationships();
relationships.AddParentAndChild(parent, child1);
relationships.AddParentAndChild(parent, child2);
new Research(relationships);
}
}
}
Law of Demeter
The Law of Demeter(or the Principle of Least Knowledge) states that “you should only speak to objects that you know about directly”. Do not do method chaining communication with other objects. An object should have as little knowledge as possible about other objects and not speak to strangers.
//Below code example is a violation of the Law of Demeter,
//Method1() of class Test1 is calling the methods of classes Test3 and Test5 //by using classes Test2 and Test5 respectively. Class Test1 is not aware of //classes Test3 and Test5. Both classes are stranger for the class Test1
public class Test1
{
public Test4 test4 { get; set; }
public Test2 test2 { get; set; }
public Test1()
{
test4 = new Test4();
test2 = new Test2();
}
public void Method1()
{
test2.test3.Test3Method();
test4.test5.Test5Method();
}
}
public class Test2
{
public Test3 test3 { get; set; }
public Test2()
{
test3 = new Test3();
}
}
public class Test3
{
public void Test3Method() { }
}
public class Test4
{
public Test5 test5 { get; set; }
public Test4()
{
test5 = new Test5();
}
}
public class Test5
{
public void Test5Method() { }
}
Refer the Link
https://en.wikipedia.org/wiki/SOLID
https://www.c-sharpcorner.com/article/the-law-of-demeter/