The SOLID principles are five programming principles which are considered to be the foundation of every well designed application.

1. S.O.L.I.D Principles
HUMAYUN KHAN

2. SOLID
 The SOLID principles are five dependency management for object oriented
programming and design.
 The SOLID acronym was introduced by Robert Cecil Martin, also known as "Uncle Bob".
 Each letter represents another three-letter acronym that describes one principle.
 When working with software in which dependency management is handled badly,
the code can become rigid, fragile and difficult to reuse.
 Rigid code is that which is difficult to modify, either to change existing functionality or
add new features.
 Fragile code is susceptible to the introduction of bugs, particularly those that appear in
a module when another area of code is changed.
If you follow the SOLID principles, you can produce code that is more flexible and robust,
and that has a higher possibility for reuse.

3. The S.O.L.I.D Principles
Single
Responsibility
Principle
Liskovs
Substitution
Principle
Dependency
Inversion
Principle

4. Single Responsibility Principle
The Single Responsibility Principle (SRP)
states that there should never be more than one
reason for a class to change.
This means that you should design your classes
so that each has a single purpose.
This does not mean that each class should have
only one method but that all of the members in
the class are related to the class's primary
function.
Where a class has multiple responsibilities,
these should be separated into new classes.
When a class has multiple responsibilities, the
likelihood that it will need to be changed
increases.
Each time a class is modified the risk of
introducing bugs grows.
By concentrating on a single responsibility, this
risk is limited.

5. SRP Violation Example
The code on LHS is a class that communicates with a hardware
device to monitor the oxygen levels in some water.
The class includes:
Method named "ReadOxygenLevel" that retrieves a value from a
stream generated by the oxygen monitoring hardware. It converts
the value to a percentage and stores it in the OxygenSaturation
property.
Second method, "OxygenLow", checks the oxygen saturation to
ensure that it exceeds the minimum level of 75%.
The "ShowLowOxygenAlert" shows a warning that contains the
current saturation value.
There are at least three reasons for change within the OxygenMeter
class.
1. If the oxygen monitoring hardware is replaced the
ReadOxygenLevel method will need to be updated.
2. If the process for determining low oxygen is changed, perhaps
to include a temperature variable, the class will need updating.
3. Finally, if the alerting requirements become more sophisticated
than outputting text to the console, the ShowLowOxygenAlert
method will need to be rewritten.

6. SRP Refactored
NB: The refactored example code on LHS
breaks other SOLID principles in order that
the application of the SRP is visible.
Further refactoring of this example is
necessary to achieve compliance with the
other four principles.

7. Open Closed Principle
Open/Closed principle says that a class should be open
for extension but closed for modification.
"Open to extension" means that you should design your
classes so that new functionality can be added as new
requirements are generated.
"Closed for modification" means that once you have
developed a class you should never modify it, except to
correct bugs.
The reason is that if you modify a class, you’ll likely
break the API/Contract of the class which means that
the classes that depend on it might fail when you do so.
If you instead inherit the class to add new features, the
base contract is untouched and it’s unlikely that
dependent classes will fail.

8. OCP Violation Example
The code in LHS is a basic module for logging
messages.
The Logger class has a single method that
accepts a message to be logged and the type of
logging to perform.
The switch statement changes the action
according to whether the program is outputting
messages to the console or to the default
printer.
If you wished to add a third type of logging, perhaps sending the logged messages to a message queue or
storing them in a database, you could not do so without modifying the existing code.
Firstly, you would need to add new LogType constants for the new methods of logging messages.
Secondly you would need to extend the switch statement to check for the new LogTypes and output or store
messages accordingly. This violates the OCP.

9. OCP Refactored
We can easily refactor the logging code to achieve compliance with the OCP.
Firstly we need to remove the LogType enumeration, as this restricts the types
of logging that can be included.
Instead of passing the type to the Logger, we will create a new class for each
type of message logger that we require.
In the final code we will have two such classes, named ConsoleLogger and
PrinterLogger.
Additional logging types could be added later without changing any existing
code.
The Logger class still performs all logging but using one of the message logger
classes described above to output a message. In order that the classes are not
tightly coupled, each message logger type implements the IMessageLogger
interface.
The Logger class is never aware of the type of logging being used as its
dependency is provided as an IMessageLogger instance using constructor
injection.

10. Liskovs Substitution Principle
Liskovs Substitution Principle states that any
method that takes class X as a parameter must
be able to work with any subclasses of X.
Robert Cecil Martin's simpler version is,
"Functions that use pointers or references to
base classes must be able to use objects of
derived classes without knowing it".
For languages such as C#, this can be changed
to "Code that uses a base class must be able to
substitute a subclass without knowing it".
The principle makes sure that every class follows
the contract defined by its parent class.

11. LSP Violation Example
The code in LHS shows the outline of several classes:
The first class represents a project that contains a number of
project files. Two methods are included that load the file data
for every project file and save all of the files to disk.
The second class describes a project file. This has a property
for the file name and a byte array that contains file data once
loaded. Two methods allow the file data to be loaded or
saved.
The third class may have been added to the solution at a later
time to the other two classes, perhaps when a new
requirement was created that some project files would be
read-only. The ReadOnlyFile class inherits its functionality
from ProjectFile. However, as read-only files cannot be
saved, the SaveFileData method has been overridden so that
an invalid operation exception is thrown.

12. The ReadOnlyFile class violates the LSP in several ways.
Although all of the members of the base class are
implemented, clients cannot substitute ReadOnlyFile
objects for ProjectFile objects.
This is clear in the SaveFileData method, which
introduces an exception that cannot be thrown by the
base class.
Next, a post-condition of the SaveFileData method in the
base class is that the file has been updated on disk. This
is not the case with the subclass. The final problem can
be seen in the SaveAllFiles method of the Project class.
Here the programmer has added an if statement to ensure
that the file is not read-only before attempting to save it.
This violates the LSP and the OCP as the Project class
must be modified to allow new ProjectFile subclasses to
be detected.
LSP Violation Example…

13. LSP Refactored
There are various ways in which the code can be refactored
to comply with the LSP.
The Project class has been modified to include
two collections instead of one. One collection contains all of
the files in the project and one holds references to writeable
files only.
The LoadAllFiles method loads data into all of the files in the
AllFiles collection. As the files in the WriteableFiles collection
will be a subset of the same references, the data will be
visible via these also.
The SaveAllFiles method has been replaced with a method
that saves only the writeable files.
The ProjectFile class now contains only one method, which
loads the file data. This method is required for both writeable
and read-only files. The new WriteableFile class extends
ProjectFile, adding a method that saves the file data.
This reversal of the hierarchy means that the code now
complies with the LSP.

14. Interface Segregation Principle
ISP states that interfaces that have become “fat”
(like god classes) should be split into several
interfaces. Large interfaces makes it harder to
extend smaller parts of the system.
In other words…
The Interface Segregation Principle (ISP) states
that clients should not be forced to depend upon
interfaces that they do not use. When we have
non-cohesive interfaces, the ISP guides us to
create multiple, smaller, cohesive interfaces. The
original class implements each such interface.
Client code can then refer to the class using the
smaller interface without knowing that other
members exist.

15. ISP Violation Example
Code in LHS shows the outline of three classes:
The Contact class represents a person or business
that can be contacted. The class holds the
person's name, address, email address and
telephone number.
The Emailer class sends email messages to
contacts. The contact and the subject and body of
the email are passed to the parameters.
The Dialler class extracts the telephone number
from the Contact and calls it using an automatic
dialling system.
The example code violates the ISP.
The Emailer class is a client of the Contact class.
Although it only requires access to the Name and
EmailAddress properties, it is aware of other
members too. Similarly, the Dialler class uses a
single property, Telephone. However, it has access
to the entire Contact interface.

16. ISP Refactored
To refactor the code to comply with the ISP we need to hide unused
members from the client classes. We can achieve this by introducing
two new interfaces, both implemented by Contact.
The IEmailable interface defines properties that hold the name and
email address of an object that can receive email.
The IDiallable interface includes only a Telephone property, which is
enough to allow client classes to call the telephone number of a
target object.
The Email class is updated, replacing the Contact dependency with
an IEmailable object.
Similarly, the Dialler's dependency becomes an IDiallable instance.
Both classes now interact with contacts using the smallest possible
interface.
With smaller interfaces it is easier to introduce new classes that
implement them. To demonstrate, the refactored code includes a new
class named MobileEngineer. This represents engineers that visit
customer sites. Engineer has properties for a name, telephone
number and vehicle registration. The class implements IDiallable so
that the Dialler object can call engineers.

17. Dependency Inversion Principle
The principle which is easiest to understand.
DIP states that you should let the caller create the
dependencies instead of letting the class itself
create the dependencies. Hence inverting the
dependency control (from letting the class control
them to letting the caller control them).
In other words…
The Dependency Inversion Principle (DIP) states
that high level modules should not depend upon
low level modules. Both should depend upon
abstractions. Secondly, abstractions should not
depend upon details. Details should depend upon
abstractions.

18. DIP Violation Example
The problem with such a design is that the high
level TransferManager class is directly dependent
upon the lower level BankAccount class.
The Source and Destination properties reference
the BankAccount type.
This makes it impossible to substitute other
account types unless they are subclasses of
BankAccount.
If we later want to add the ability to transfer money
from a bank account to pay bills, the BillAccount
class would have to inherit from BankAccount.
Further problems arise should changes be
required to low level modules.
A change in the BankAccount class may break the
TransferManager. In more complex scenarios,
changes to low level classes can cause problems
that cascade upwards through the hierarchy of
modules. As the software grows, this structural
problem can be compounded and the software
can become fragile or rigid.

19. DIP Refactored
Applying the DIP resolves these problems by
removing direct dependencies between classes.
To comply with the DIP we must remove the
direct dependency that the TransferManager
has on the BankAccount class. We could
introduce a new interface for accounts that
contains the methods we require to add and
remove funds. However, in this case I have
introduced two new interfaces. ITransferSource
includes a method that allows funds to be
removed from an account. ITransferDestination
includes the method for adding funds to an
account.
The separation of the two interfaces complies with the Interface Segregation Principle (ISP)
and allows for the inclusion of accounts that accept payments but cannot be the source of
funds. The BankAccount class is modified so that it implements the new interfaces.
TransferManager is modified so that the Source property expects an ITransferSource object
and the destination is an ITransferDestination. No direct dependencies on concrete classes
now exist. Instead, both the high level class and the low level class depend upon the two
abstractions.