Skip to content

In this project, i try to explain solid principle with examples

License

Notifications You must be signed in to change notification settings

CeyhunAslan/SOLID

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 

Repository files navigation

SOLID

In this project, i try to explain solid principle with examples

Ekran görüntüsü 2022-03-07 175353

SOLID

SOLID is a popular set of design principles that are used in object-oriented software development. SOLID is an acronym that stands for five key design principles: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. All five are commonly used by software engineers and provide some important benefits for developers.

Single Responsibility Principle (SRP)

Robert Martin summarizes this principle well by mandating that, “a class should have one, and only one, reason to change.” Following this principle means that each class only does one thing and every class or module only has responsibility for one part of the software’s functionality. More simply, each class should solve only one problem.

I showed wrong usage and correct usage. (GitHub Pages)

Open-Closed Principle

The idea of open-closed principle is that existing, well-tested classes will need to be modified when something needs to be added. Yet, changing classes can lead to problems or bugs. Instead of changing the class, you simply want to extend it. With that goal in mind, Martin summarizes this principle, “You should be able to extend a class’s behavior without modifying it.”

Following this principle is essential for writing code that is easy to maintain and revise. Your class complies with this principle if it is:

Open for extension, meaning that the class’s behavior can be extended; and Closed for modification, meaning that the source code is set and cannot be changed.

I showed wrong usage and correct usage. (GitHub Pages)

Liskov Substitution Principle

The Liskov Substitution Principle states that any subclass object must be substitutable for the superclass object from which it derives. This semantic relationship, often referred to as behavioral subtyping, is applied to develop more accurate, extensible and reusable software.

I showed wrong usage and correct usage. (GitHub Pages)

Interface Segregation Principle

The general idea of interface segregation principle is that it’s better to have a lot of smaller interfaces than a few bigger ones. Martin explains this principle by advising, “Make fine grained interfaces that are client-specific. Clients should not be forced to implement interfaces they do not use.”

I showed wrong usage and correct usage. (GitHub Pages)

Dependency Inversion Principle

This principle offers a way to decouple software modules. Simply put, dependency inversion principle means that developers should “depend on abstractions, not on concretions.” Martin further explains this principle by asserting that, “high level modules should not depend upon low level modules. Both should depend on abstractions.” Further, “abstractions should not depend on details. Details should depend upon abstractions.”

I showed wrong usage and correct usage. (GitHub Pages)

Don't Repeat Yourself

"Don't repeat yourself" (DRY) is a software development principle that aims to reduce duplication of software patterns, replace it with abstractions, or use data normalization to avoid redundancy.

I showed wrong usage and correct usage. (GitHub Pages)

Keep it Simple Stupid

Keep it simple, stupid (KISS) is a design principle which states that designs and/or systems should be as simple as possible. Wherever possible, complexity should be avoided in a system—as simplicity guarantees the greatest levels of user acceptance and interaction.

I showed wrong usage and correct usage. (GitHub Pages)

You Aren't Gonna Need It

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it

I showed wrong usage and correct usage. (GitHub Pages)