SOLID

Question 1

SRP

Answer 1

Single Responsibility

Question 2

OCP

Answer 2

Open/Closed Principle (OCP)
Software entities should be open for extension but closed for modification.
You should be able to add new functionality without changing existing code. This is often done through interfaces or inheritance.
* You don’t want to have one class that has hardcoded or fixed methods in it. For example, a Payment Processor class. You don’t want just one class that handles different types of payment methods like credit card, paypal, and applepay. You want to have multiple classes for each payment method that inherit from a parent PaymentMethod class. Then within each of the subclasses you can process the payment.

Question 3

LSP

Answer 3

Objects of a superclass should be replaceable with objects of its subclasses without altering the correctness of the program.
If you have a parent class and a child class, you should be able to use the child class anywhere the parent class is expected, and things should still work as intended.
* You don’t want to set up child classes that won’t work/raise errors because the child class doesn’t honor the expected behavior of the parent class. For example, setting up a parent class of Bird, with a method for fly. If you create a child class of Penguin that inherits from Bird and you set up a fly method that will raise an error saying “Penguins can’t fly!”, this breaks the LSP rule.

Question 4

ISP

Answer 4

Clients should not be forced to depend on interfaces they do not use.
It’s better to have many small, specific interfaces rather than a large, general-purpose one. This prevents classes from being burdened with methods they don’t need.
* You don’t want to set up child classes that don’t need all of the inherited methods of the parent class. For example, setting up a parent class of Worker, with methods work and take_break. If you set up an Intern class that inherits from Worker but the intern doesn’t need to use the take_break method, then this is breaking the ISP rule.

Question 5

DIP

Answer 5

High-level modules should not depend on low-level modules. Both should depend on abstractions.
This encourages the use of interfaces or abstract classes to decouple higher-level components from lower-level details, making the code more modular and easier to change.
You want to set up multiple classes that interact with each other and handle