OOPS Design Principles(Completing course)
Writing a Method that takes one or few parameters as input and then returns various Outputs depends on the logic of the function. This post will be dedicated on the OOPS design Principles and how those somehow complete Design principles for software development. All the principles in SOLID are somehow connected with each other and one can follows any one of those for Better development of code. Follow any principle(Say Open-Close) and after some time of developing your code you will find that you actually are following all the principles. 🙂 Because all these principles are developed by making one thing in mind and that is High-Quality Software development.
S(Solid Responsibility Principle): There should never be more than one reason to for a class to change.
O(Open-Close Principle): Classes(Modules or functions) should be open for extensions but closed for modifications.
***Features should be parameterized in the way that class can be overridden.
OCP suggests that some bug fixes should be viewed as an extensions instead of a modifications.
That clarifies the single responsibility principle. A class should be able to do only on kind of task. Kind means Reading data. Data could be read from one type of file or many type of files. For example there could be class name DataReader() and it could have many methods. csv_reader(), excel_reader(), db_reader(), txt_reader() so now single-responsibility of class is to ‘read data’ 🙂 any kind of data, by any means but read data. 🙂
Any class that we are going to write should be written as is it could be extended but no need to make new changes in the code of the class.
Interface Segregation Principle: (I from SOLID)
*** No client should be forced to depend on methods it does not use.
*** Class should be designed so collaborators should have narrowest interface.
*** If you are using Python Unit Test cases should be there because we are using Python!
Classes that implement interfaces should not be forced to implement methods they(classes) do not use. (Use small interfaces not FAT ones) Do not create fat interfaces.
We need different streams for read and write.
A client should be dependent on smallest set of Methods and attributes. The fewest methods or attributes.
Segregation defines parting the functions(Not programming functions) of Software into two or more different classes for ease of client to access the features.
D: Dependency inversion principle.
*** Applications should use abstract class code that lead to injection.
*** In language like Python we can use settings.py file to perform tasks like this one.
High level modules should not be dependent on low level modules. Abstractions should not be dependent on Details, Details should depend on abstractions. There should be one ‘Abstraction-Layer’ on each of the module so one would be able to test the behavior of classes without even looking at the classes.
L:(Liskov substitution Principle):
*** Behavior of sub-class should be as correct as behavior of super class.
When you will follow the Liskov substitution principle your classes will follow Open/Close principles implicitly.
Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).
Single responsibility principle:
** A class should have only one reason to change.
GRASP:>>>> General Responsibility assignment principle.
**Controller and Creation
**High Cohesion and Indirection
** High Cohesion:
Features those belong together.
High Cohesion are combined into single responsibility.
** Hard part is locating level of abstractions.
Why we should think about GRASP?: