Extensão da Memória

SOLID - Single Responsibility Principle (SRP) The Single Responsibility Principle states that a class should have only one reason to change. In other words, a class should have a single responsibility or purpose. Here's an example: class FileManager: def read_file(self, file_path): # Code to read the file def write_file(self, file_path, content): # Code to write content to the file def compress_file(self, file_path): # Code to compress the file def decompress_file(self, file_path): # Code to decompress the file In the above example, the FileManager class violates the SRP because it has multiple responsibilities. It handles file reading, writing, compression, and decompression. A better approach would be to separate these responsibilities into distinct classes, each with a single responsibility. For example: class FileReader: def read_file(self, file_path): # Code to read the file class FileWriter: def write_fil

SOLID - Dependency Inversion Principle (DIP) Dependency Inversion Principle emphasizes decoupling and abstraction in software systems by defining guidelines for dependency relationships between modules or classes. High-level modules should not depend on low-level modules. Both should depend on abstractions. In simpler terms, DIP encourages the use of interfaces or abstract classes to define contracts and dependencies between modules, rather than depending on concrete implementations. This allows for flexibility, extensibility, and easier maintenance of the codebase. To adhere to DIP, the following practices are recommended: Programming to interfaces or abstract classes rather than concrete implementations. Using dependency injection to provide dependencies to classes rather than instantiating them directly. Employing dependency inversion frameworks or inversion of control containers to manage object dependencies. DIP and Multiple Inheritance This is a special case of Depende

SOLID - Liskov Substitution Principle (LSP) The Liskov Substitution Principle (LSP) is a fundamental principle in object-oriented programming (OOP) that defines guidelines for substitutability of objects within a program's inheritance hierarchy. It states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In simpler terms, the LSP emphasizes that derived classes or subclasses must be able to be used in place of the base class without introducing unexpected behavior or breaking the functionality of the program. The principle can be summarized with the following statement: "If S is a subtype of T, then objects of type T can be replaced with objects of type S without altering the correctness of the program." Design by Contract (DbC) To adhere to the Liskov Substitution Principle, derived classes must follow these guidelines: Subtype Requirement: The contract or behavior defined by the base

SOLID - Open-Closed Principle (OCP) The Open-Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. It means that you should be able to extend the behavior of a software entity without modifying its existing code. from abc import ABC, abstractmethod class Area(ABC): @abstractmethod def calculate_area(self): pass class Rectangle(Area): def __init__(self, length, width): self.length = length self.width = width def calculate_area(self): return self.length * self.width class Circle(Area): def __init__(self, radius): self.radius = radius def calculate_area(self): return 3.14 * self.radius ** 2 def print_areas(shapes): for shape in shapes: area = shape.calculate_area() print(f"Area: {area}") # Client code shapes = [Rectangle(4, 5), Circle(3)] print_areas(shapes) SOLID and Design Pattern Open-Clos