https://github.com/julianamancera/dependency-inversion

https://github.com/julianamancera/dependency-inversion

Last synced: 3 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/julianamancera/dependency-inversion
• Owner: JulianaMancera
• Created: 2024-05-01T14:47:02.000Z (about 1 year ago)
• Default Branch: main
• Last Pushed: 2024-05-11T02:55:23.000Z (about 1 year ago)
• Last Synced: 2024-08-12T04:25:40.520Z (9 months ago)
• Language: Java
• Size: 14.6 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • Changelog: Newspaper.java

Awesome Lists containing this project

README

        
# Dependency-Inversion

## NEU Library Resource Management System 


**Problem**


  The NEU Library offers a variety of resources, including books, theses, capstones, internet access, journals, and newspapers. Currently, the system for managing student borrowing directly depends on specific resource types, violating the Dependency Inversion Principle (DIP) and hindering flexibility for future changes. 


### UML Class Diagram 


+ **Resource:** An interface representing a generic library resource with method borrow().

+ **Book, Thesis, Capstone, InternetAccess, Journal, Newspaper:** Concrete classes implementing the Resource interface, each representing a specific type of library resource.

+ **ResourceManagement:** A class responsible for managing the borrowing and returning of resources.

+ **Student:** A class representing a student with properties name and id, and methods to access these properties.

+ **LibrarySystem:** Validates the refactored code by creating a Student object and borrowing different types of resources.
 


![UML DIP](https://github.com/Julsaurus/Dependency-Inversion/assets/133284711/d4d337d2-b34c-48eb-a9f9-e7363a5f57b3) 


### Solution 


  To follow the Dependency Inversion Principle (DIP) and ensure flexibility for future changes, the system must be refactored while adhering to SOLID principles. The proposed solution adds an abstraction layer between the Student class and the individual resource types. This abstraction separates the Student class from concrete resource implementations, allowing for the seamless integration of new resource types in the future.