Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/laeth0/solid

This repository provides examples of SOLID principles, illustrating both good and bad practices.
https://github.com/laeth0/solid

Last synced: 9 days ago
JSON representation

This repository provides examples of SOLID principles, illustrating both good and bad practices.

Host: GitHub
URL: https://github.com/laeth0/solid
Owner: laeth0
Created: 2024-07-25T15:35:52.000Z (4 months ago)
Default Branch: main
Last Pushed: 2024-07-25T15:44:18.000Z (4 months ago)
Last Synced: 2024-07-25T18:06:28.293Z (4 months ago)
Language: Java
Size: 56.6 KB
Stars: 0
Watchers: 1
Forks: 0
Open Issues: 0
Metadata Files:
- Readme: README.md

Awesome Lists containing this project

README

        ## SOLID Principles

![Cover](https://github.com/mman9our/SOLID_Principles/assets/72463762/0c6fc35e-4b5a-4249-ad7c-1cabd5b3352a)

SOLID is an acronym that stands for:

- `SRP`: Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have only one responsibility or job.

- `OCP`: Open-Closed Principle (OCP): Software entities (classes, modules, functions) should be open for extension but closed for modification. This means that we should be able to extend the behavior of a

- `LSP`: Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In other words, a subclass should be able to replace its parent class without breaking the program's functionality.

- `ISP`: Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This principle encourages creating smaller, specific interfaces rather than large, monolithic ones.

- `DIP`: Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This principle promotes loose coupling between modules and easier maintenance.