Notification

A one-method interface for reaching an offline player, with implementations chosen at startup based on which plugins are installed.

When Medieval Factions needs to tell a player something and that player is offline, it hands the message to an MfNotificationService. The interface has one method and no return value.

Three implementations, chosen once

setupNotificationService() is a single when expression evaluated during onEnable:

1. Mailboxes — if the Mailboxes plugin is installed, the message waits in the player's in-game mail.
2. RPKit — otherwise, if rpk-notification-lib-bukkit is installed.
3. No-op — otherwise, the message is discarded.

The order is a preference, not a negotiation: with both installed, Mailboxes wins and RPKit is never consulted. The rest of the codebase never learns which was chosen. MfFaction.sendMessage illustrates the intended use: message online members directly, and route the offline ones through the notification service.

Degrading quietly

The Mailboxes implementation begins by fetching the plugin from Bukkit's plugin manager and casting it, returning immediately on a null or failed cast. A notification to an unreachable backend is dropped, not raised.

That is the right call for this particular payload — a faction announcement is not worth a stack trace in the console on every send, and the alternative (throwing from a notification path) would let a missing optional dependency break faction operations. It does mean a misconfigured server loses messages silently.

Why an interface at all

The no-op implementation is the tell. Rather than scatter if (mailboxesInstalled) checks through the codebase, the plugin resolves the question once at startup and lets the type system carry the answer. This is the same shape as Map Integration, and it is the pattern to copy when integrating any optional plugin.

Related

The MfNotification record itself is just a title and a body — no severity, no routing hints. Anything richer would have to be encoded in the text.