As with everything in life, using these principles mindlessly\ncan cause more harm than good. The cost of applying these\nprinciples into a program’s architecture might be making it\nmore complicated than it should be. there’s no successful software product in which all of these principles are applied at once. Striving for these principles is good, but always try to be pragmatic and don’t take everything written here as dogma.
\nThese principles called the S.O.L.I.D principles is an acronym derived by Michael Feathers. S: Single Responsibility Principle O: Open-Closed Principle L: Liskov Substitution Principle I: Interface Segregation Principle D: Dependency Inversion Principle.\nSo let’s start with them briefly:
\n1-Single Responsibility Principle
\nA class should have just one reason to change.\nTry to make every class responsible for a single part of\nthe functionality provided by the software.\nMake that responsibility entirely encapsulated.\nOne reason to change\nNotice The main goal of this principle is to reduce complexity.\nYou don’t need to invent a sophisticated design for a program that\nonly has about 200 lines of code. Make a dozen methods pretty,\nand you’ll be fine.\nThe real problems emerge when your program constantly grows and changes.
\n2- Open/Closed Principle
\nClasses should be open for extension.\nBut at the same time close for modification.\nThe main idea of this principle is to keep existing\ncode from breaking when you implement new features.
\n3- Liskov Substitution Principle
\nWhen extending a class, remember that you should be\nable to pass objects of the subclass in place of objects of\nthe parent class without breaking the client code.\nThis means that the subclass should remain compatible with the behavior of the superclass. When overriding a method,\nextend the base behavior rather than replacing it with something else entirely.
\nThis concept is critical when developing libraries and\nframeworks because your classes are going to be used\nby other people whose code you can’t directly access and change.
\nInvariants are conditions in which an object makes sense.\nFor example, invariants of a cat are having\nfour legs, a tail, the ability to meow, etc.
\n4- Interface Segregation Principle (ISP)
\nClients shouldn’t be forced to depend on methods they do not use.\nISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.\nAnd notice Correct abstraction is the key to Interface Segregation Principle.
\n5- Dependency Inversion Principle (DIP)
\nHigh-level classes shouldn’t depend on low-level classes.\nBoth should depend on abstractions. Abstractions shouldn’t depend on details. Details should depend on\nabstractions.
\nTo make a distinction between low and high-level classes\n• Low-level classes implement basic operations such as working\nwith a disk, transferring data over a network, connecting to a\ndatabase, etc.\n• High-level classes contain complex business logic that directs\nlow-level classes to do something.
\nIn quick words how to implement DIP\nA-Build low-level classes\nB-Build its interface based on abstraction\nC-Build high-level classes
\nConclusion
\nWe discussed briefly the solid principles when designing software,\nalthough you would never implement them each project you wok with,\nIn the other hand; it is good to put those principles on notice when\ncoding or when design the software by the architect.
","timeToRead":2,"frontmatter":{"title":"The \"SOLID\" Principles in designing software","date":"August 12, 2019","spoiler":"brief introduction to the SOLID principles in programming","tags":"SOLID JS Priciplal_Learning Coding"},"fields":{"slug":"/SOLID-Principles/","langKey":"en"}}},"pageContext":{"slug":"/SOLID-Principles/","previous":{"fields":{"slug":"/Depedency-Inversion/","langKey":"en","directoryName":"Depedency-Inversion","maybeAbsoluteLinks":[]},"frontmatter":{"title":"What is depedency inversion"}},"next":{"fields":{"slug":"/Functional/","langKey":"en","directoryName":"Functional","maybeAbsoluteLinks":[]},"frontmatter":{"title":"Functional programming"}},"translations":[],"translatedLinks":[]}}}