100 Days of Code - Day 18 Object Oriented Programming
4 min read
Hello! My name is Rick and I am in search for gig as a developer :)
SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle Bob).
These principles can apply to various programming languages and were established as a guide for programmers to follow in order to avoid code smells, refactoring code, and supports Agile and Adaptive software development.
SOLID stands for:
- S - Single-responsiblity Principle
- O - Open-closed Principle
- L - Liskov Substitution Principle
- I - Interface Segregation Principle
- D - Dependency Inversion Principle
Single Responsibility Principle
A class, function, etc should only have ONE responsibility. It is important to follow this principle because quite often as an application grows, the code will need to be updated or changed. Following this principle also makes the code easier to read by someone else.
Below is an example of bad practice. Notice the function has multiple responsibilities.
Instead, each function has ONE responsibility
The functionality in code should be OPEN to extension and CLOSED to modification. You do not want to change the existing code, but you can add to it as the application grows. Again, practicing this principal avoids a mess and bugs in your code. For example, if we have a class that calculates the area of a circle and would want to add the ability to calculate the area of a different shape, then we could add an if statement. On the other hand, what about making a 'shape' class and adding children to that class that have their own methods.
Why is open-close important?
- When you modify a class or method, there may be unexpected outcomes and bugs.
- If you work for a larger company, they may have features set in place that have been throughly tested.
- When you add an extension there is confidence that the existing code will be safe!
Liskov Substitution Principle
- Ability to replace any instance of a parent class with an instance of one of its child classes without negative side effects. If the child class does not have the same variables and methods as the parent then the principal is not adhered to and the code will have bugs. However, you can make a new class that is a child and add functionality (modify)
Interface Segregation Principle
- Interfaces should be granularly split and be as small as possible.
- Code should not depend on methods it doesn't use.
Check out the code below. We have a parent Vehicle class and because a motorcycle class can not use auto drive, it breaks the principal. Methods can not be unused that are inherited from parent classes.
class Vehicle(): def accelerate(self): raise NotImplementedError def brake(self): raise NotImplementedError def impliment_auto_drive(self): raise NotImplementedError class TeslaSelfDriving(Vehicle): def accelerate(self): print('implimentation to accelerate') def brake(self): print('implimentation to brake') def impliment_auto_drive(self): print('implimentation to auto drive') class MotorCycle(self): def accelerate(self): print('implimentation to accelerate') def brake(self): print('implimentation to brake') def impliment_auto_drive(self): raise NotImplementedError
solution below where interfaces are split
from abc import ABC, abstractclassmethod class Accelerate(ABC): def accelerate(self): pass class Brake(ABC): def brake(self): pass class AutoDrive(ABC): def impliment_auto_drive(self): pass class TeslaSelfDriving(Accelerate, Brake, AutoDrive): def accelerate(self): print('implimentation to accelerate') def brake(self): print('implimentation to brake') def impliment_auto_drive(self): print('implimentation to auto drive') class MotorCycle(Accelerate, Brake): def accelerate(self): print('implimentation to accelerate') def brake(self): print('implimentation to brake')
Dependency Inversion Principle
- Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module(implementations), but they should depend on abstractions.
You are a CEO of Coka-Cola with many responsibilities
drive a truck
do tax stuff
You would only manage
More to follow on Dependency Inversion Principle with examples.