Wie gehe ich mit zusätzlichen Parametern für verschiedene Implementierungen einer Schnittstelle in Java um? ⇐ Java

[Guest]

Ich arbeite an einem Spring Boot-Projekt, in dem ich eine Notifier-Schnittstelle mit einer send(String message)-Methode habe. Verschiedene Implementierungen von Notifier, wie FCMNotifier und SNSNotifier, erfordern zusätzliche Parameter zum Senden von Benachrichtigungen (z. B. Token, Themen usw.).
Hier ist ein Beispiel meiner Schnittstelle und zwei Implementierungen:

Code: Select all

public interface Notifier {
void send(String message);
}

@Component
public class FCMNotifier implements Notifier {

@Override
public void send(String message) {
// Use token to send message via FCM
// need token

}
}

@Component
public class SNSNotifier implements Notifier {

@Override
public void send(String message) {

// Use topicArn to send message via SNS
// need topicArn
}
}

Wie Sie sehen, erfordert jede Implementierung zusätzliche Parameter (token für FCMNotifier und topicArn für SNSNotifier). Ich möchte dieses Design flexibler machen und eine enge Kopplung der Parameter an bestimmte Implementierungen vermeiden.
Meine Frage:
Wie kann ich solche zusätzlichen Parameter für verschiedene Implementierungen am besten handhaben? eine skalierbare und wartbare Möglichkeit?
Sollte ich so etwas wie ein Kontextobjekt verwenden, um Parameter dynamisch zu übergeben? Oder gibt es bessere Entwurfsmuster, um dieses Problem zu lösen?
Sollte ich stattdessen einen Builder hinzufügen, um häufige Anforderungen zu bearbeiten?
Ich habe versucht, sowohl das Builder-Muster als auch das Decorator-Muster zu verwenden, um die Flexibilität zu verbessern und Skalierbarkeit. Ich erwartete, dass das Builder-Muster beim dynamischen Erstellen von Benachrichtigungen mit verschiedenen Parametern (wie Token oder Themen) helfen würde und dass das Decorator-Muster es mir ermöglichen würde, zusätzliche Verhaltensweisen (z. B. Protokollierungs- oder Wiederholungsmechanismen) rund um den Benachrichtigungsprozess zu schichten. Ich bin mir jedoch nicht sicher, ob dies der richtige Ansatz ist oder ob es bessere Muster oder Praktiken gibt, die ich für diesen Anwendungsfall in Betracht ziehen sollte.