MUGOYA DIHFAHSIH

A Pythonic Guide to SOLID Design Principles People that know me will tell you I am a big fan of the SOLID Design Principles championed by Robert C. Martin (Uncle Bob)). Over the years I've used these principles in C#, PHP, Node.js, and Python. Everywhere I took them they were generally well-received...except when I started working in Python. I kept getting comments like "It's not a very Pythonic way to do things" during code review. I was new to Python at the time so I didn't really know how to respond. I didn't know what Pythonic code meant or looked like and none of the explanations offered were very satisfying. It honestly pissed me off. I felt like people were using the Pythonic way to cop-out of writing more disciplined code. Since then I've been on a mission to prove SOLID code is Pythonic. That's the wind up now here's the pitch. What is SOLID Design Michael Feathers can be credited for creating the mnemonic SOLID which is based on

This article aims to give a  solid  explanation of SOLID Principles and give some insight on their benefits and potential issues when applying them. Let’s go through each of them briefly. S — Single Responsibility Principle(S.R.P) A class should have one, and only one, reason to change. When requirements change, this implies that the code has to undergo some reconstruction, meaning that the classes have to be modified. The more responsibilities a class has, the more change requests it will get, and the harder those changes will be to implement. The responsibilities of a class are coupled to each-other, as changes in one of the responsibilities may result in additional changes in order for the other responsibilities to be handled properly by that class. What is a responsibility?! A responsibility can be defined as a reason for change. Whenever we think that some part of our code is potentially a responsibility, we should consider separating it from the class. Let’s say we