You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello Stationary Shop Management Development Team,
This issue documents the analysis and refactoring carried out for the transaction management system of the stationery store. The goal was to improve the code structure by addressing previously identified violations of SOLID principles.
UML Diagram
Changes Made
Single Responsibility Principle (SRP): The Shop class had multiple responsibilities, such as managing the catalog, purchases, sales, and reports by date. Now, it is divided into ProductManager for product management and OperationManager for operation management.
Open/Closed Principle (OCP): The Shop was not closed to modification. Now, OperationManager uses the OperationExecutable interface, allowing new types of operations like Loan and Return to be added without modifying the base class.
Liskov Substitution Principle (LSP): Purchase, Sale, and Damage were not completely substitutable by the base class OperationOnProduct. The OperationExecutable interface was created, and the classes were adjusted to ensure that all implement the same contract, ensuring consistency and compatibility.
Dependency Inversion Principle (DIP): Shop depended on concrete classes (Purchase, Sale, Damage). Now it depends on the abstraction OperationExecutable and uses OperationManager to execute operations, eliminating the coupling with specific classes.
New Classes Implemented
OperationManager: Manages the registration and query of operations for the stationery, using a list of OperationExecutable to handle the registered operations.
ProductManager: Exclusively manages the product catalog, with methods to list and query products.
OperationExecutable (Interface): Defines the contract for operations (execute(), getDate(), getQuantity(), and getType()), allowing any specific operation to be handled uniformly.
ProductManageable (Interface): Defines the contract for product management, allowing methods for listing and querying products to be implemented.
This updated design resolves SOLID principle violations, enhances system flexibility, and facilitates adding new functionality without modifying existing classes.
The text was updated successfully, but these errors were encountered:
Hello Stationary Shop Management Development Team,
This issue documents the analysis and refactoring carried out for the transaction management system of the stationery store. The goal was to improve the code structure by addressing previously identified violations of SOLID principles.
UML Diagram
Changes Made
Single Responsibility Principle (SRP): The Shop class had multiple responsibilities, such as managing the catalog, purchases, sales, and reports by date. Now, it is divided into ProductManager for product management and OperationManager for operation management.
Open/Closed Principle (OCP): The Shop was not closed to modification. Now, OperationManager uses the OperationExecutable interface, allowing new types of operations like Loan and Return to be added without modifying the base class.
Liskov Substitution Principle (LSP): Purchase, Sale, and Damage were not completely substitutable by the base class OperationOnProduct. The OperationExecutable interface was created, and the classes were adjusted to ensure that all implement the same contract, ensuring consistency and compatibility.
Dependency Inversion Principle (DIP): Shop depended on concrete classes (Purchase, Sale, Damage). Now it depends on the abstraction OperationExecutable and uses OperationManager to execute operations, eliminating the coupling with specific classes.
New Classes Implemented
OperationManager: Manages the registration and query of operations for the stationery, using a list of OperationExecutable to handle the registered operations.
ProductManager: Exclusively manages the product catalog, with methods to list and query products.
OperationExecutable (Interface): Defines the contract for operations (execute(), getDate(), getQuantity(), and getType()), allowing any specific operation to be handled uniformly.
ProductManageable (Interface): Defines the contract for product management, allowing methods for listing and querying products to be implemented.
Modified Code
Shop.java
Product.java
OperationOnProduct.java
Damage.java
Sale.java
Purchase.java
ProductManageable.java
ProductManager.java
OperationExecutable.java
OperationManager.java
This updated design resolves SOLID principle violations, enhances system flexibility, and facilitates adding new functionality without modifying existing classes.
The text was updated successfully, but these errors were encountered: