Being in the IT industry for 7 Years, I was lucky to work with multiple companies from early age- startups to Fortune 500. Most of them were very different in their work procedures & work ethics. Yet, Surprisingly similar in one area: lowering the expenses at the detremint of proper system architecture. <\/p>\n-A System Architect <\/cite><\/blockquote>\n\n\n\n Before we begin with our System Design Principles, let’s fuss over the definition of “Technical Debt.” Technical Debt is the result we get when we prioritize the speedest deployment over code. <\/p>\n\n\n\n If you are familiar with OOPS, then you must have heard about SOLID principles. These five software development serves as a foundation for building software products that are easier to scale & maintain. <\/p>\n\n\n\n However, there are serious consequences of not using SOLID principles such as Rigidity, Immobility, Coupling & viscosity. <\/strong><\/p>\n\n\n\n Further in this article, we’ll discuss the SOLID software design principles In detail. Read till the end, and you will learn several tips that can save you time & trouble while writing code. <\/p>\n\n\n\n Interested in switching to Full-stack development career? Ensure you’re solid on full-stack development essentials like front-end frameworks, back-end technologies, and database management. Join HCL GUVI\u2019s Full Stack Development Course<\/a><\/strong> with Placement Assistance. You will be able to master the MERN stack<\/a> (MongoDB, Express.js, React, Node.js<\/a>) and build real-life projects.<\/p>\n\n\n\n Solid is an acronym for 5 software design principles that assists us to keep technical debt under control.<\/p>\n\n\n\n The main goal of SOLID is to make you & your tech team more productive which can only happen if the whole code is maintainable through decoupling and decomposition. Let’s deconstruct SOLID principles into their letters. <\/p>\n\n\n\n <\/a> ROADMAP TO FULL STACK DEVELOPMENT + SYLLABUS (UPDATED) <\/a><\/em><\/strong><\/em><\/strong><\/p>\n\n\n\n A class, function, or module should have a single responsibility. They all should have only one reason to change.<\/em><\/p>\n\n\n\n If a class, module, or function has many responsibilities, it increases the probability of bugs. Making a crucial change to one of its responsibilities could affect the other ones without the developer’s knowledge. To comprehend it in easy words “Responsibility” can be defined as a reason to change, and each entity should have one, and only one reason to change. <\/p>\n\n\n\n One reason to change = > one responsibility!<\/strong><\/p>\n\n\n\n The main objective of this principle is decoupling. <\/strong>If classes will have a separate behavior, and in case a bug arrives, it won’t hamper other unrelated behaviors. Thus creating an organized hierarchy in software design. <\/p>\n\n\n\n Class, modules,<\/em> or functions should be open for extensibility but closed for modification. Although, BUG fixing is okay.<\/em><\/p>\n\n\n\n Modifications are an integral part of software design & its evolution. But if you have already upgraded to a stable build, modifications can trigger instability. Hence for a right-hand thumb rule avoid modifications, rather evolution should progress based on extension. <\/p>\n\n\n\n The principle is eminent in Production! For instance-open source libraries. The premise is that if a developer has created and published some class modification in the class can break the implementation of those, who have started using this specific class. <\/p>\n\n\n\n OCP was originally described in the context of inheritance, where you should always prefer composition over inheritance as it is easier\/malleable to modify later. OCP minimizes the risk of regression bugs & enforces decoupling by isolating changes in specific components. Nevertheless, It’s not the hard end rule? <\/p>\n\n\n\n Subsets should be subsituatble for their base type. <\/em><\/p>\nBarbara Liskov, 1987<\/cite><\/blockquote>\n\n\n\n If A is a subtype of B then all the objects of type B in a program may be replaced with objects of type A without altering any of the desirable properties of that program. <\/p>\n\n\n\n The principle explains how polymorphism <\/strong>should work, and not how it actually works, but how it should work. Needless to say, achieving clean substitution of the entities is not easy as it sounds. There are 6 rules to ensure LSP. <\/p>\n\n\n\n An ideology that no client should be forced to depend upo<\/em>n the interfaces that they do not use. <\/p>\n\n\n\n Many methods are written in a single large interface, and the class implementing that interface has to implement redundant methods. When a class is instructed to execute an action that is not useful or wasteful, it may trigger unexpected bugs. instead of this, we should split the interface into multiple smaller interfaces. So that we can keep the methods in the interface as granular as possible. Avoid redundancy. <\/p>\n\n\n\n Please note that “interface” in the above principle name does not strictly adhere to the interface, it could be an abstract class. <\/p>\n\n\n\n High-level modules should not depend on low-level modules. In fact, Both should be dependent on abstraction. <\/em><\/p>\n<\/div>\n\n\n\n Abstraction should not rely on details, details should rely on abstraction. <\/em> <\/p>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n\n\n Sometimes modules with great complex structures come under scrutiny when we modify or update modules at a much lower level. This is a horrifying experience for any software developer especially when software needs frequent revamp. SOLID’s last principle dependency inversion principle solves the specific issue using a key rule that High-level modules & low-level modules should never be codependent. Entities must depend on abstractions, not on concretions. <\/p>\n\n\n\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. if you are working on Spring Framework, you might be familiar with this principle. <\/p>\n\n\n\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. Thus reducing the dependency of high-level classes on a low-level classes by introducing an interface. <\/p>\n\n\n\n So we have summarized five integral pillars of software design principles. These SOLID principles will help you make your code easy to adjust, extend and test with little to no problems.<\/p>\n\n\n\n For more such engaging & thoughtful content on Software development<\/a>, enroll in HCL GUVI’s Career Programs<\/a> offering a springboard for knowledge & deep dive into in-demand streams: Full Stack Development, Data Science, Automation Testing, Data Engineering<\/em>, UI UX Design & more.<\/p>\n\n\n\n It’s Industry’s leading live online class platform, that offers placement support & IIT-M recognized certifications<\/a>. <\/p>\n\n\n\n What are software design principles? And why it’s a right-hand thumb rule to apply certain design principles in software engineering? For those unfamiliar with the term, Software engineering is a systematic & procedural approach to software development. Being in the IT industry for 7 Years, I was lucky to work with multiple companies from early […]<\/p>\n","protected":false},"author":11,"featured_media":9814,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[294],"tags":[],"views":"6346","authorinfo":{"name":"Tushar Vinocha","url":"https:\/\/www.guvi.in\/blog\/author\/tushar\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/1_wrxj0oBKpA_GXb8LPhXOeg-300x111.png","jetpack_featured_media_url":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/1_wrxj0oBKpA_GXb8LPhXOeg.png","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/9809"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=9809"}],"version-history":[{"count":18,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/9809\/revisions"}],"predecessor-version":[{"id":103294,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/9809\/revisions\/103294"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/9814"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=9809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=9809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=9809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Technical Debt??<\/h2>\n\n\n\n
\n
![\"Technical](\"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/Screenshot-2022-03-31-at-4.05.34-PM-300x264.png\" "\\"\\"")
\n
\n\n\n\nSOLID-An integral part of Software Design Principles <\/h2>\n\n\n\n
S–Single Responsibility Principle (SRP) <\/h2>\n\n\n\n
What If SRP is absent? <\/h3>\n\n\n\n
\n
\n\n\n\nO–Open closed principle (OCP)<\/h2>\n\n\n\n
Should we use OCP every time? No. <\/h3>\n\n\n\n
\n
\n\n\n\nL–Liskov Substitution Principles (LSP) <\/h2>\n\n\n\n
\n
![\"Liskov_Substitution_Principles\"](\"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/1_yKk2XKJaCLNlDxQMx1r55Q-1142x1024.png\" "\\"\\"")
<\/figure>\n\n\n\n\n
\n\n\n\nI–Interface Segregation Principle (ISP)<\/h2>\n\n\n\n
![\"Interface-Segregation-software-design-principels-SOLID\"](\"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/1_2hmyR9L43Vm64MYxj4Y89w-1200x601.png\" "\\"\\"")
<\/figure>\n\n\n\nThe benefits of applying ISP<\/h3>\n\n\n\n
\n
\n\n\n\nD–Dependency Inversion Principle <\/h2>\n\n\n\n
![\"Dependency_Inversion_Principle](\"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2022\/06\/Dependency-Inversion-1200x628.png\" "\\"\\"")
<\/figure>\n\n\n\nWrapping up<\/h2>\n\n\n\n
![\"Full](\"http:\/\/blog.guvi.in\/wp-content\/uploads\/2022\/06\/Discovery-FSD-3-1200_628-1200x628.png\" "\\"\\"")
<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"