{"id":7385,"date":"2020-07-13T20:54:36","date_gmt":"2020-07-13T18:54:36","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=7385"},"modified":"2020-07-13T11:55:57","modified_gmt":"2020-07-13T09:55:57","slug":"the-s-o-l-i-d-principles-in-pictures","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2020\/07\/13\/the-s-o-l-i-d-principles-in-pictures\/","title":{"rendered":"The S.O.L.I.D Principles in Pictures"},"content":{"rendered":"

If you are familiar with Object-Oriented Programming, then you\u2019ve probably heard about the SOLID principles.<\/p><\/blockquote>\n

Ugonna Thelma<\/a><\/span> explains The S.O.L.I.D Principles in Pictures<\/a> <\/em>and she explains them very well.<\/p>\n

In fact I shall admit that while I’ve interiorized the S, the O, the L and the I, I always tend to forget the “Dependency injection” principle. Now it’s really clear!<\/p>\n

<\/p>\n

\n

The S.O.L.I.D Principles in Pictures<\/h1>\n
\n
\n
\n
\"Ugonna<\/a>Ugonna Thelma<\/a><\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n
\n
\n
\"\"\/<\/a>*All illustrations in this article are by <\/strong>Ugonna Thelma<\/strong><\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

If you are familiar with Object-Oriented Programming<\/a>, then you\u2019ve probably heard about the SOLID<\/strong><\/a> principles.<\/p>\n

These 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<\/a>.<\/p>\n

There are so many great articles online about SOLID<\/strong> but I rarely see any examples with pictures. This makes it a bit difficult for visual learners like me to learn while staying engaged.<\/p>\n

So the main aim of this article is to get a better understanding of these principles using illustrations and emphasizing the goal for each principle.<\/p>\n

You see, some of these principles may look similar but they are not targeting the same goal<\/strong>. It is possible to satisfy one principle while violating the other, even though they are alike.<\/p>\n

To make this as simple to follow, I will be using the word \u201cClass\u201d<\/strong> but note that it can also apply to a Function<\/strong>, Method<\/strong> or Module<\/strong> in this article.<\/p>\n

Now, let\u2019s begin!<\/p>\n

The SOLID Principles<\/h1>\n

S \u2014 Single Responsibility<\/h2>\n
\n

A class should have a single responsibility<\/p>\n<\/blockquote>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

If 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.<\/p>\n

Goal<\/strong><\/p>\n

This principle aims to separate behaviours so that if bugs arise as a result of your change, it won\u2019t affect other unrelated\"\"\/<\/a> behaviours.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
\n

O \u2014 Open-Closed<\/h2>\n
\n

Classes should be open for extension, but closed for modification<\/p>\n<\/blockquote>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n
\n
\n
<\/div>\n

\"\"\/<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n

Changing the current behaviour of a Class will affect all the systems using that Class.<\/p>\n

If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.<\/p>\n

Goal<\/strong><\/p>\n

This principle aims to extend a Class\u2019s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
\n

L <\/strong>\u2014 Liskov Substitution<\/strong><\/p>\n

\n

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.<\/p>\n<\/blockquote>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

When a child<\/strong> Class cannot perform the same actions as its parent<\/strong> Class, this can cause bugs.<\/p>\n

If you have a Class and create another Class from it, it becomes a parent<\/strong> and the new Class becomes a child. <\/strong>The child<\/strong> Class should be able to do everything the parent<\/strong> Class can do. This process is called Inheritance<\/strong>.<\/p>\n

The child<\/strong> Class should be able to process the same requests and deliver the same result as the parent<\/strong> Class or it could deliver a result that is of the same type.<\/p>\n

The picture shows that the parent<\/strong> Class delivers Coffee(it could be any type of coffee). It is acceptable for the child<\/strong> Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.<\/p>\n

If the child<\/strong> Class doesn\u2019t meet these requirements, it means the child<\/strong> Class is changed completely and violates this principle.<\/p>\n

Goal<\/strong><\/p>\n

This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
\n

I <\/strong>\u2014 Interface Segregation<\/strong><\/p>\n

\n

Clients should not be forced to depend on methods that they do not use.<\/p>\n<\/blockquote>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n
\n

When 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.<\/p>\n

A 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.<\/p>\n

Goal<\/strong><\/p>\n

This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.<\/mark><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
\n

D <\/strong>\u2014 Dependency Inversion<\/strong><\/p>\n

\n

– High-level modules should not depend on low-level modules. Both should depend on the abstraction.<\/p>\n

– Abstractions should not depend on details. Details should depend on abstractions.<\/p>\n<\/blockquote>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n

Firstly, let\u2019s define the terms used here more simply<\/p>\n

High-level Module(or Class)<\/strong>: Class that executes an action with a tool.<\/p>\n

Low-level Module (or Class)<\/strong>: The tool that is needed to execute the action<\/p>\n

Abstraction<\/strong>: Represents an interface that connects the two Classes.<\/p>\n

Details<\/strong>: How the tool works<\/p>\n

This 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.<\/p>\n

It 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.<\/p>\n

Goal<\/strong><\/p>\n

This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n
\n

Summary<\/h1>\n

So far, we have discussed these five principles and highlighted their goals. They are to help you make your code easy to adjust, extend and test with little to no problems.<\/p>\n

Thank you so much for reading. I hope you have a better idea about this topic and you had as much fun reading this as I did writing it.<\/p>\n

If you have any questions or suggestions, leave a comment or reach out to me on Twitter@<\/em><\/strong><\/a>ugonna_t<\/strong><\/a>.<\/p>\n<\/div>\n<\/div>\n<\/section>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"

If you are familiar with Object-Oriented Programming, then you\u2019ve probably heard about the SOLID principles. Ugonna Thelma explains The S.O.L.I.D Principles in Pictures and she explains them very well. In fact I shall admit that while I’ve interiorized the S, the O, the L and the I, I always tend to forget the “Dependency injection”…<\/p>\n

Read more →<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"link","meta":{"inline_featured_image":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[72,34],"tags":[],"class_list":["post-7385","post","type-post","status-publish","format-link","hentry","category-documentations","category-eiffel","post_format-post-format-link"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6daft-1V7","jetpack-related-posts":[{"id":4917,"url":"https:\/\/monodes.com\/predaelli\/2018\/11\/14\/single-responsibility-principle\/","url_meta":{"origin":7385,"position":0},"title":"Single Responsibility Principle","author":"Paolo Redaelli","date":"2018-11-14","format":false,"excerpt":"Writing Flexible Code with the Single Responsibility Principle Mhmhmm... where have I heard of that SOLID principle? Ah, Eiffel! Severin Perez Writer | Developer | Information Specialist Sep 7 Writing Flexible Code with the Single Responsibility Principle SOLID Principles and Maintainable Code Photo by NASA on\u00a0Unsplash If you\u2019ve been around\u2026","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4948,"url":"https:\/\/monodes.com\/predaelli\/2018\/11\/19\/maintainable-code-and-the-open-closed-principle-severin-perez-medium\/","url_meta":{"origin":7385,"position":1},"title":"Maintainable Code and the Open-Closed Principle \u2013 Severin Perez \u2013 Medium","author":"Paolo Redaelli","date":"2018-11-19","format":false,"excerpt":"A Look at the Open-Closed Principle in JavaScript Maintainable Code and the Open-Closed Principle \u2013 Severin Perez \u2013 Medium Oh, another interesting article that tries to educate the \"unliterate\" JavaScript masses about the basic principle behind Eiffel..... Maintainable Code and the Open-Closed Principle Abstraction and the Open-Closed Principle in JavaScript\u2026","rel":"","context":"In "Documentations"","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1771,"url":"https:\/\/monodes.com\/predaelli\/2016\/09\/17\/reform-copyright\/","url_meta":{"origin":7385,"position":2},"title":"Reform Copyright","author":"Paolo Redaelli","date":"2016-09-17","format":false,"excerpt":"Reform Copyright Education, parody, photography, and remix shouldn\u2019t be unlawful online. It\u2019s time to set our imaginations free in the EU \u2014 sign Mozilla\u2019s petition: Reform Copyright It's time our laws caught up with our technology. Did you know making a meme technically isn't allowed in many parts of the\u2026","rel":"","context":"In "Copyright"","block_context":{"text":"Copyright","link":"https:\/\/monodes.com\/predaelli\/category\/copyright\/"},"img":{"alt_text":"","src":"https:\/\/d3n8a8pro7vhmx.cloudfront.net\/mozillafoundation\/pages\/19\/attachments\/original\/1471399032\/1f4a5.svg?1471399032","width":350,"height":200,"srcset":"https:\/\/d3n8a8pro7vhmx.cloudfront.net\/mozillafoundation\/pages\/19\/attachments\/original\/1471399032\/1f4a5.svg?1471399032 1x, https:\/\/d3n8a8pro7vhmx.cloudfront.net\/mozillafoundation\/pages\/19\/attachments\/original\/1471399032\/1f4a5.svg?1471399032 1.5x"},"classes":[]},{"id":5033,"url":"https:\/\/monodes.com\/predaelli\/2018\/12\/10\/sans-forgetica-rmit\/","url_meta":{"origin":7385,"position":3},"title":"Sans Forgetica – RMIT","author":"Paolo Redaelli","date":"2018-12-10","format":false,"excerpt":"Sans Forgetica is a typeface designed using the principles of cognitive psychology to help you to better remember your study notes. Source: Sans Forgetica - RMIT","rel":"","context":"In "Fonts"","block_context":{"text":"Fonts","link":"https:\/\/monodes.com\/predaelli\/category\/fonts\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1500,"url":"https:\/\/monodes.com\/predaelli\/2016\/05\/05\/object-oriented-and-functional-programming\/","url_meta":{"origin":7385,"position":4},"title":"Object oriented and functional programming","author":"Paolo Redaelli","date":"2016-05-05","format":false,"excerpt":"\u00a0Object oriented and functional programming Learn how functional programming can help you implement the SOLID design principles. I shall attend this as soon as possible \u00a0 \u00a0 \u00a0","rel":"","context":"In "Documentations"","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2340,"url":"https:\/\/monodes.com\/predaelli\/2017\/04\/02\/modules-vs-microservices\/","url_meta":{"origin":7385,"position":5},"title":"Modules vs. microservices","author":"Paolo Redaelli","date":"2017-04-02","format":"link","excerpt":"Apply modular system design principles while avoiding the operational complexity of microservices. Modules vs. microservices Modules vs. microservices Apply modular system design principles while avoiding the operational complexity of microservices. By Sander Mak March 24, 2017 Container (source: Antranias). Register for the O'Reilly Software Architecture Conference in New York, April\u2026","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/7385","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/comments?post=7385"}],"version-history":[{"count":0,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/7385\/revisions"}],"wp:attachment":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/media?parent=7385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/categories?post=7385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/tags?post=7385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}