Scribd
Upload
98 views9 pages

SOLID

The document discusses the SOLID principles of object-oriented design. It defines SOLID as an acronym for five principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. The principles provide guidelines for building robust, extensible, and maintainable object-oriented applications by arranging code into well-designed classes and interfaces.

Uploaded by

Aung Khaing Min
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
98 views9 pages

SOLID

The document discusses the SOLID principles of object-oriented design. It defines SOLID as an acronym for five principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. The principles provide guidelines for building robust, extensible, and maintainable object-oriented applications by arranging code into well-designed classes and interfaces.

Uploaded by

Aung Khaing Min
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

DESIGN PRINCIPLE

SOLID

• SOLID is the acronym for a set of practices that, when implemented


together, make the code more adaptive to change.
• Bob Martin and Micah Martin introduced these concepts in their book
‘Agile Principles, Patterns, and Practices’.
• The acronym was meant to help us remember these principles easily.
• SOLID principles form the fundamental guidelines for building object-
oriented applications that are robust, extensible, and maintainable.
SOLID

• Good software systems begin with clean code.

• The SOLID principles tell us how to arrange our functions and data structures into
classes, and how those classes should be interconnected.

• The goal of the principles is the creation of mid-level software structures


that:
• Tolerate change
• Are easy to understand, and
• Are the basis of components that can be used in many software systems.
SOLID PRINCIPLE

• Single Responsibility Principle (SRP)


• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)]
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle(DIP)
SINGLE RESPONSIBILITY PRINCIPLE(SRP)

❑ The single responsibility principle states that every java class must
perform a single of functionality.

❑ Implementation of multiple functionalities in a single class mashup the


code.

❑ “One class should have one and only one responsibility”


OPEN-CLOSED PRINCIPLE(OCP)

❑ The open-closed principle states that according to new requirements


the module should be open for extension but closed for modification.

❑ “Software components should be open for extension, but closed for


modification”
LISKOV SUBSTITUTION PRINCIPLE (LSP)

❑ It applies to inheritance in such a way that the derived classes must be


completely substitutable for their base classes.

❑ In other words, if class A is a subtype of class B, then we should be able


to replace B with A without interrupting the behavior of the program.

❑ “Derived types must be completely substitutable for their base types”


INTERFACE SEGREGATION PRINCIPLE(ISP)

❑ The principle states that the larger interfaces split into smaller ones.
❑ Because the implementation classes use only the methods that are required.
❑ We should not force the client to use the methods that they do not want to
use.
❑ The goal of the interface segregation principle is similar to the single
responsibility principle.
❑ “Clients should not be forced to implement unnecessary methods which they
will not use”
DEPENDENCY INVERSION PRINCIPLE (DIP)

❑ The principle states that we must use abstraction (abstract classes and
interfaces) instead of concrete implementations.

❑ High-level modules should not depend on the low-level module but


both should depend on the abstraction.

❑ “Depend on abstractions, not on concretions”

You might also like