{"id":19346981,"url":"https://github.com/guardianofgods/the-solid-principles","last_synced_at":"2025-04-13T01:39:57.726Z","repository":{"id":207101956,"uuid":"718434116","full_name":"GuardianOfGods/the-solid-principles","owner":"GuardianOfGods","description":null,"archived":false,"fork":false,"pushed_at":"2023-11-14T04:19:24.000Z","size":3573,"stargazers_count":4,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-04-13T01:39:17.810Z","etag":null,"topics":["c-sharp","documents","oop","oop-programming","oriented-object-programming","principles","programming","solid","unity-learning"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/GuardianOfGods.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-11-14T04:06:48.000Z","updated_at":"2025-01-21T07:16:30.000Z","dependencies_parsed_at":null,"dependency_job_id":"43faf311-0445-4819-b297-fb096a4fdf8f","html_url":"https://github.com/GuardianOfGods/the-solid-principles","commit_stats":null,"previous_names":["guardianofgods/the-solid-principles"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GuardianOfGods%2Fthe-solid-principles","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GuardianOfGods%2Fthe-solid-principles/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GuardianOfGods%2Fthe-solid-principles/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GuardianOfGods%2Fthe-solid-principles/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/GuardianOfGods","download_url":"https://codeload.github.com/GuardianOfGods/the-solid-principles/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248654027,"owners_count":21140236,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c-sharp","documents","oop","oop-programming","oriented-object-programming","principles","programming","solid","unity-learning"],"created_at":"2024-11-10T04:13:31.543Z","updated_at":"2025-04-13T01:39:57.703Z","avatar_url":"https://github.com/GuardianOfGods.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\n\n# The S.O.L.I.D Principles in Pictures\n\n![alt text](images/1.png \"S.O.L.I.D\")\n\nIf you are familiar with [Object-Oriented Programming](https://en.wikipedia.org/wiki/Object-oriented_programming), then you’ve probably heard about the [**SOLID**](https://en.wikipedia.org/wiki/SOLID) principles.\n\n\nThese five software development principles are guidelines to follow when building software so that it is easier to scale and maintain. They were made popular by a software engineer, Robert C. Martin.\n\nThere are so many great articles online about **SOLID** but I rarely see any examples with pictures. This makes it a bit difficult for visual learners like me to learn while staying engaged.\n\nSo the main aim of this article is to get a better understanding of these principles using illustrations and emphasizing the goal for each principle.\n\nYou see, some of these principles may look similar but they are not targeting **the same goal**. It is possible to satisfy one principle while violating the other, even though they are alike.\n\nTo make this as simple to follow, I will be using the word “**Class**” but note that it can also apply to a **Function**, **Method** or **Module** in this article.\n\n**Update**\n\nI got some comments about the Open Closed in this article violating the Single Responsibility Principle. Please note that the aim of this article is to explain each of these principles independent of the others.\nAlso, Responsibilities(or Roles) are different from Actions. \n\nIn SRP, I used “I am Painter”, in Open-Closed, I used “I can Paint”.\nIt is important to note this because several actions can be performed to fulfil a responsibility(or role). The class should have one responsibility(SRP) but its functionality that fulfils that responsibility should be open to extend(OCP).\n\nNow, let’s begin!\n\n\n## The SOLID Principles\n\n### S — Single Responsibility\n\n\u003e A class should have a single responsibility\n\n![alt text](images/2.png \"Single Responsibility\")\n\nIf a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.\n\n**Goal**\n\nThis principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.\n\n### O — Open-Closed\n\n\u003e Classes should be open for extension, but closed for modification\n\n![alt text](images/3.png \"Open-Closed\")\n\nChanging the current behaviour of a Class will affect all the systems using that Class.\nIf you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.\n\n**Goal**\n\nThis principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.\n\n### L — Liskov Substitution\n\n\u003e If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.\n\n![alt text](images/4.png \"Liskov Substitution\")\n\nWhen a **child** Class cannot perform the same actions as its **parent** Class, this can cause bugs.\n\nIf you have a Class and create another Class from it, it becomes a **parent** and the new Class becomes a **child**. The **child** Class should be able to do everything the **parent** Class can do. This process is called **Inheritance**.\n\nThe **child** Class should be able to process the same requests and deliver the same result as the **parent** Class or it could deliver a result that is of the same type.\n\nThe picture shows that the **parent** Class delivers Coffee(it could be any type of coffee). It is acceptable for the **child** Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.\n\nIf the child Class doesn’t meet these requirements, it means the child Class is changed completely and violates this principle.\n\n**Goal**\n\nThis principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.\n\n### I — Interface Segregation\n\n\u003e Clients should not be forced to depend on methods that they do not use.\n\n![alt text](images/5.png \"Interface Segregation\")\n\nWhen a Class is required to perform actions that are not useful, it is wasteful and may produce unexpected bugs if the Class does not have the ability to perform those actions.\n\nA Class should perform only actions that are needed to fulfil its role. Any other action should be removed completely or moved somewhere else if it might be used by another Class in the future.\n\n**Goal**\n\nThis principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.\n\n### D — Dependency Inversion\n\n\u003e - High-level modules should not depend on low-level modules. Both should depend on the abstraction.\n\n\u003e - Abstractions should not depend on details. Details should depend on abstractions.\n\n![alt text](images/6.png \"Dependency Inversion\")\n\nFirstly, let’s define the terms used here more simply\n\n**High-level Module(or Class)**: Class that executes an action with a tool.\n\n**Low-level Module (or Class)**: The tool that is needed to execute the action\n\n**Abstraction**: Represents an interface that connects the two Classes.\n\n**Details**: How the tool works\n\nThis principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.\n\nIt also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.\n\n**Goal**\n\nThis principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.\n\n## LICENSE\nOpen-sourced software licensed under the [MIT license](http://opensource.org/licenses/MIT).\n\n## Summary\nThe article is written by **Ugonna Thelma**. Here is the [original link](https://github.com/ugonnathelma/articles/blob/master/the-solid-principles-in-pictures/the-solid-principles-in-pictures.md)\n\nHope it's helpul to you ❤️.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fguardianofgods%2Fthe-solid-principles","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fguardianofgods%2Fthe-solid-principles","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fguardianofgods%2Fthe-solid-principles/lists"}