{"id":248,"date":"2020-02-01T00:50:45","date_gmt":"2020-02-01T00:50:45","guid":{"rendered":"http:\/\/pragmaticways.com\/?p=248"},"modified":"2020-04-05T18:10:02","modified_gmt":"2020-04-05T18:10:02","slug":"5-solid-principles-all-software-engineers-need-to-follow","status":"publish","type":"post","link":"https:\/\/pragmaticways.com\/5-solid-principles-all-software-engineers-need-to-follow\/","title":{"rendered":"SOLID Principles: The fundamental Object Oriented design principles"},"content":{"rendered":"\n

What does SOLID principles mean?<\/h2>\n\n\n\n

Proper planning prevents poor performance<\/p><\/blockquote>\n\n\n\n

You don’t want your software to have poor performance, do you? Do you want a poor design? An un-maintainable code base that other developers are scared to update because they can’t understand what the software is doing?<\/p>\n\n\n\n

SOLID principles are a set of standard design principles that all software engineers should be familiar with and understand when building software.<\/p>\n\n\n\n

As Hackernoon explains,<\/p>\n\n\n\n

When the developer builds a software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.<\/p>Hackernoon – SOLID Principles: A Simple and Easy Explanation<\/a><\/cite><\/blockquote>\n\n\n\n

SOLID principles is an acronym which consists of 5 design principles:<\/p>\n\n\n\n\n\n

Single Responsibility Principle<\/h2>\n\n\n\n

A class should have one and only one reason to change<\/p><\/blockquote>\n\n\n\n

You may often head the Single Responsibility Principles referred to as “a class should only have one responsibility.” Given the principle’s name, this description should be pretty self explanatory. But a better way to think about this principle is “a class should have only one reason to change<\/em>.”<\/strong><\/p>\n\n\n\n

Every time you change or need to make an update to a class, you risk the possibility of breaking something inside that class. The more “things” that class does, the more chances there are for you to break something! You can mitigate this risk by creating smaller classes with a more focused, targeted responsibility. <\/p>\n\n\n\n

I think Robert (Uncle Bob) Martin explains it best in his book Clean Code. I’ll paraphrase his description here on why creating more, smaller classes is better than creating a few, large classes:<\/p>\n\n\n\n

If you have a collection of tools, would you prefer to have one large drawer where you throw all your tools in, or would you rather have your tools organized into many small drawers each containing well-defined labels? <\/p>\n\n\n\n

By the way, if you haven’t yet, you should read his book. You can pick up a copy of it here:<\/p>\n\n\n\nEvery software engineer must read this book >><\/span><\/span>