frereriku/dependency-injection-with-quicklewiper

1. This repository is a tiny Java console demo focused on Dependency Injection (DI), using a “Quickle Wiper” cleaning tool as the domain model. Its purpose is educational: show how a main object can be kept independent from interchangeable parts.

2. The code is split into two clear subsystems:

- cleaningdidemo.core: the reusable “device” side

- cleaningdidemo.sheets: the interchangeable “attachment” side

This is the key architectural boundary in the repo.

3. cleaningdidemo.Main is the entry point. It is responsible for wiring the objects together and starting the demo. In DI terms, this is where the object graph is assembled rather than hidden inside the core classes.

4. cleaningdidemo.core.QuickleWiper is the central domain object. It represents the wiper body itself and depends on a sheet/cloth abstraction or sheet-like object rather than a specific concrete implementation. That separation is the main design lesson of the repository.

5. The cleaningdidemo.sheets package contains the replaceable implementations of the wiping surface:

- CleaningSheet

- CheapSheet

- DustCloth

- GenuineSheet

These classes represent different variants that can be swapped without changing the QuickleWiper class.

6. The main data flow is simple:

- Main chooses a sheet implementation

- Main passes it into QuickleWiper

- QuickleWiper uses that injected dependency to perform its cleaning behavior

This demonstrates constructor-style or explicit object injection at the composition boundary.

7. The architecture is intentionally layered but not framework-driven. There is no web layer, persistence layer, or external service integration. The entire repo is a small, in-memory object model meant to isolate the DI concept as clearly as possible.

8. The package names suggest a clean dependency direction:

- Main depends on both core and sheets

- core should depend on an abstraction or minimal contract, not on a specific sheet class

- sheets are leaf implementations and should not depend on core

This one-way dependency structure is what makes substitution possible.

9. The repository is likely designed to show the difference between coupling to a concrete class versus depending on a swappable part. The presence of multiple sheet classes implies that the same QuickleWiper behavior can be reused with different consumables.

10. Tooling/runtime is minimal:

- Java 17

- Compile with javac cleaningdidemo/Main.java

- Run with java cleaningdidemo.Main

There is no build system metadata in the tree, so the architecture is deliberately lightweight and self-contained.

11. For an architecture diagram, the most important boxes are:

- Main as composition root

- QuickleWiper as the core consumer

- the four sheet classes as interchangeable implementations

The main arrow should show dependency injection from Main into QuickleWiper.

12. The overall design goal is not business functionality but demonstrability: show how a core class stays stable while variants are swapped at construction time. That is the central architectural idea of the repo.