PAR-300
0
Kill the static god-object surface on ChestShop.java: DI the messenger, de-static the service refs, relocate the pure helper
Pending ReleaseNormalUnassignedChestShopImprovement
The plugin main class had accumulated a static service-locator/god surface. Cleaned the parts that are genuinely misplaced logic/state (leaving only true plugin infrastructure):
sendBungeeMessage(4 static overloads + private) → new@Singleton services/BungeeMessengerinjectingMessage+ChestShopConfiguration+JavaPlugin. Injected into its 2 real callers (TransactionService, ShowItemHook). The unusedString/BaseComponent[]overloads were dropped.values()(pure message-map builder, 6 callers) → pureutils/Messages.values(...). It's a pure function, so a util — not a DI bean (DI is for collaborators, not pure functions).- static service refs
message/itemCodes/accounts→messagedeleted (only the bungee methods used it);itemCodes/accountsde-static'd to instance fields (they're the main class's own enable-time orchestration).
Deliberately kept: the Bukkit-plugin infrastructure accessors (getBukkitLogger [69 callers], getPlugin, getBukkitServer, getVersion, getMetrics, callEvent, runInAsyncThread). A static logger accessor is legitimate plugin infra and matches Business's pattern; injecting loggers into ~30 classes would be churn without architectural gain.
:chestshop:build green; server enables cleanly (BungeeMessenger constructs via injected JavaPlugin); ChestShop suite 42/42.
Resources
- commitdb57e11 Kill the static god-object surface on ChestShop.java via DI (PAR-300)ParadauxIO/hibernia-economy
Comments
No comments yet.
Activity
- tesks changed status to Status → Pending Release
- ParadauxIO linked a commit — Commit db57e11 — Kill the static god-object surface on ChestShop.java via DI (PAR-300)
- tesks created the issue