This document provides an overview and examples of the SOLID principles of object-oriented design: - SRP (Single Responsibility Principle) states that a class should have one, and only one, reason to change. Examples show extracting validation and email sending logic into separate classes. - OCP (Open-Closed Principle) states that software entities should be open for extension but closed for modification. Examples use inheritance and interfaces to add new filtering logic without modifying existing classes. - LSP (Liskov Substitution Principle) states that subclasses must be substitutable for their base classes. Examples show invalid implementations that break the base class contract. - ISP (Interface Segregation Principle

1. SOLID
Principles of Object Oriented Design

2. Why SOLID?
SOLID is a set of five guiding principles that help developers design objects that
are easy to maintain and use.
Like many similar sets of principles in OO, SOLID is a guide not the goal.

3. Solid SRP
Single
Responsibility
Principle

4. sOolid OCP
Open /
Closed
Principle

5. soLid LSP
Liskov
Substitution
Principle

6. solId ISP
Interface
Segregation
Principle

7. soliD DIP
Dependency
Inversion
Principle

8. SRP
Single Responsibility Principle
One work at a time

9. “One work at a time”
● A class or module should have ONLY ONE
reason to change. Several reasons of change
may lead to several (and unwanted)
redeployments.
● Several responsibilities become coupled.
Coupled design is fragile.
SRP
Single
Responsibility
Principle

10. Example - Single Responsibility Principle
public class UserService
{
public void Register(string email, string password)
{
if (!ValidateEmail(email))
throw new ValidationException("Email is not an email");
var user = new User(email, password);
SendEmail(new MailMessage("mysite@nowhere.com", email) { Subject="HEllo foo" });
}
public virtual bool ValidateEmail(string email)
{
return email.Contains("@");
}
public bool SendEmail(MailMessage message)
{
_smtpClient.Send(message);
}
}

11. Example - Single Responsibility Principle
public class UserService
{
EmailService _emailService;
DbContext _dbContext;
public UserService(EmailService aEmailService,
DbContext aDbContext)
{
_emailService = aEmailService;
_dbContext = aDbContext;
}
public void Register(string email, string password)
{
if (!_emailService.ValidateEmail(email))
throw new ValidationException("Email is
not an email");
var user = new User(email, password);
_dbContext.Save(user);
emailService.SendEmail(new
MailMessage("myname@mydomain.com",
email)
{Subject="Hi. How are you!"});
}
}
public class EmailService
{
SmtpClient _smtpClient;
public EmailService(SmtpClient aSmtpClient)
{
_smtpClient = aSmtpClient;
}
public bool virtual ValidateEmail(string email)
{
return email.Contains("@");
}
public bool SendEmail(MailMessage message)
{
_smtpClient.Send(message);
}
}
read: http://www.objectmentor.com/resources/articles/srp.pdf

12. OCP
Open/Closed Principle
Open for extension / Closed for modification

13. Software entities (classes, modules,
functions, etc.) should be open for
extension, but closed for modification:
● A module is open if it is available for extension. For
example, it should be possible to add fields to the
data structures it contains, or new elements to the
set of functions it performs.
● A module is closed if it is available for use by other
modules. This assumes that the module has been
given a well-defined, stable description (the interface
in the sense of information hiding)
OCP
Open/
Closed
Principle

14. Example - Open/Closed Principle
public class ProductFilter
{
public IEnumerable<Product> ByColor(IList<Product> products, ProductColor
productColor)
{
foreach (var product in products)
{
if (product.Color == productColor)
yield return product;
}
}
public IEnumerable<Product> ByColorAndSize(IList<Product> products,
ProductColor productColor, ProductSize productSize)
{
foreach (var product in products)
{
if ((product.Color == productColor) && (product.Size == productSize))
yield return product;
}
}
public IEnumerable<Product> BySize(IList<Product> products, ProductSize productSize)
{
foreach (var product in products)
{
if ((product.Size == productSize))
yield return product;
}
}
}

15. Example - Open/Closed Principle
public abstract class ProductFilterSpecification
{
public IEnumerable<Product> Filter(IList<Product> products)
{
return ApplyFilter(products);
}
protected abstract IEnumerable<Product> ApplyFilter
(IList<Product> products);
}
public class ColorFilterSpecification : ProductFilterSpecification
{
private readonly ProductColor productColor;
public ColorFilterSpecification(ProductColor productColor)
{
this.productColor = productColor;
}
protected override IEnumerable<Product> ApplyFilter
(IList<Product> products)
{
foreach (var product in products)
{
if (product.Color == productColor)
yield return product;
}
}
}
public class ProductFilter
{
public IEnumerable<Product> By(IList<Product>
products, ProductFilterSpecification
filterSpecification)
{
return filterSpecification.Filter(products);
}
}
OCP using the Template Design Pattern
read: http://www.objectmentor.com/resources/articles/ocp.pdf

16. LSP
Liskov Substitution Principle
Subclasses should be substitutable for their base classes

17. ● Child classes should never break the parent
class' type definitions
● The parent class should easily replace the
child class
LSP
Liskov
Substitution
Principle

18. Example - Liskov Substitution Principle
public interface IDuck
{
void Swim();
bool IsSwimming { get; }
}
public class OrganicDuck : IDuck
{
public void Swim()
{
//do something to swim
}
bool IsSwimming { get { /* return if the duck is
swimming */ } }
}
public class ElectricDuck : IDuck
{
bool _isSwimming;
public void Swim()
{
if (!IsTurnedOn)
throw new Exception("Duck sink!");
_isSwimming = true;
//swim logic
}
bool IsSwimming { get { return _isSwimming; } }
}
void MakeDuckSwim(IDuck duck)
{
duck.Swim(); //exception if duck is ElectricDuck
}
void MakeDuckSwim(IDuck duck)
{
if (duck is ElectricDuck)
((ElectricDuck)duck).TurnOn();
duck.Swim();
}

19. Example - Liskov Substitution Principle
public class Account
{
public Account(int AccountId)
{
this.Id = AccountId;
}
public virtual int Id { get; set; }
public virtual void Withdraw(int accountId, int
amount)
{
Console.WriteLine("In base withdraw");
}
}
public class SavingAccount : Account
{
public SavingAccount(int savingAccountId):
base(savingAccountId)
{
}
public override void Withdraw(int accountId,
int amount)
{
Console.WriteLine("In SavingAccount
withdraw");
}
}
public class CurrentAccount : Account
{
public CurrentAccount(int currentAccountId) :
base(currentAccountId)
{
}
public override void Withdraw(int accountId, int
amount)
{
Console.WriteLine("In CurrentAccount withdraw");
}
}
Account account = new Account(1);
account.Withdraw(acc, 100);
Account saving = new SavingAccount(2);
saving.Withdraw(saving, 100);
read:http://www.objectmentor.com/resources/articles/lsp.pdf

20. ISP
Interface Segregation Principle
Client Specific Interfaces

21. ● no client should be forced to implement methods it
does not use
● split large interfaces into smaller and more specific
so the clients will know about the methods that are
interested in
● keep components focused in order to achieve low
coupling and high cohesion
● ISP is similar to SRP: one purpose => one interface!
ISP
Interface
Segregation
Principle

22. Example - Interface Segregation Principle
public abstract class Animal
{
public abstract void Feed();
public abstract void Groom();
}
public class Dog : Animal
{
public override void Feed()
{
//do something
}
public override void Groom()
{
// do something
}
}
public class Rattlesnake : Animal
{
public override void Feed()
{
// do something
}
public override void Groom()
{
throw new Exception("Not Implemented
yet or better Ignore!");
}
}
public interface IPet
{
void Groom();
}
public abstract class Animal
{
public abstract void Feed();
}
public class Dog : Animal, IPet
{
public override void Feed()
{
// do something
}
public void Groom()
{
// do something
}
}
public class Rattlesnake : Animal
{
public override void Feed()
{
// do something
}
}
read: http://www.objectmentor.com/resources/articles/isp.pdf

23. DIP
Dependency Inversion Principle
Abstractions Should Not Depend on Details

24. ● Abstractions should not depend upon details;
● Details should depend upon abstraction
● High-level modules implement business logic in a
system (application). Low-level modules deal with
more detailed operations, in other words they may
deal with writing information to databases or passing
messages to the operating system or services.
DIP
Dependency
Inversion
Principle

25. Example - Dependency Inversion Principle
class Customer
{
private FileLogger obj = new FileLogger();
public virtual void Add()
{
try
{
// Database code goes here
}
catch (Exception ex)
{
obj.Handle(ex.ToString());
}
}
}

26. Example - Dependency Inversion Principle
interface ILogger
{
void Handle(string error);
}
class FileLogger : ILogger
{
public void Handle(string error)
{
System.IO.File.WriteAllText(@"c:Error.txt",
error);
}
}
class EverViewerLogger : ILogger
{
public void Handle(string error)
{
// log errors to event viewer
}
}
class EmailLogger : ILogger
{
public void Handle(string error)
{
// send errors in email
}
}
class Customer : IDiscount, IDatabase
{
private Ilogger obj;
public Customer(ILogger i)
{
obj = i;
}
}
read: http://www.objectmentor.com/resources/articles/dip.pdf

27. SOLID (review)
● S for SRP (Single responsibility principle)
A class should take care of only one responsibility.
● O for OCP (Open closed principle)
Extension should be possible without modification.
● L for LSP (Liskov substitution principle)
A parent class object should be able to refer child objects seamlessly during runtime polymorphism.
● I for ISP (Interface segregation principle)
Client should not be forced to use a interface if it does not need it.
● D for DIP (Dependency inversion principle)
High level modules should not depend on low level modules but should depend on abstraction.

28. Panagiotis Pnevmatikatos
pnevmap@gmail.com
Reading suggestion
Clean Code
Book by Robert Cecil Martin