Die Verwaltung mehrerer Zahlungsmethoden ist einer der schwierigsten Aspekte beim Erstellen einer mobilen Anwendung. Jede Zahlungsmethode – ob Kreditkarten, PayPal, Apple Pay, Google Pay oder regionenspezifische Wallets wie Alipay und WeChat Pay – verfügt über eine eigene API, Validierungsregeln, Fehlerbehandlung und Compliance-Anforderungen. Das Hinzufügen einer neuen Methode bedeutet oft, mehrere Teile der Codebasis zu berühren und Risiko und Regression einzuführen.

Das Factory-Muster bietet eine strukturierte Lösung für diese Komplexität. Durch die zentrale Erstellung von Zahlungsmethodenobjekten entkoppelt es den Client-Code von den konkreten Implementierungen von Zahlungen. Dadurch wird Ihre App wartbarer, testbarer und skalierter, wenn neue Zahlungsoptionen unvermeidlich erscheinen.

In diesem Artikel werden wir untersuchen, wie man das Factory-Muster zur Verwaltung verschiedener Zahlungsmethoden in mobilen Apps anwendet, mit praktischen Beispielen und Best Practices.Wir werden auch diskutieren, wie dieses Muster mit modernen Architekturen wie MVVM und Clean Architecture übereinstimmt und wie man es mit Backend-Diensten wie Directus integrieren kann, um Zahlungskonfigurationen dynamisch zu speichern und abzurufen.

Das Fabrikmuster verstehen

Das Factory-Muster ist ein Schöpfungsdesign-Muster, das eine Schnittstelle zum Erstellen von Objekten in einer Superklasse bietet, aber Unterklassen erlaubt, die Art der Objekte zu ändern, die erstellt werden. Einfacher ausgedrückt, es kapselt die Instanziationslogik ein, so dass Clients die konkreten Klassen nicht kennen müssen; sie interagieren nur mit einer gemeinsamen Schnittstelle.

Dieses Muster ist besonders wertvoll in mobilen Apps, wo die Anzahl der Zahlungsmethoden mit der Zeit wachsen kann. Ohne eine Fabrik könnten Sie am Ende große oder -Anweisungen haben, die über Ihre Codebasis verteilt sind und von denen jede weiß, wie man eine bestimmte Zahlungsmethode konstruiert. Dieser Ansatz verstößt gegen das Open/Closed-Prinzip und macht den Code starr – das Hinzufügen einer neuen Zahlungsmethode erfordert die Änderung jedes Ortes, an dem eine solche erstellt wird.

Das Factory-Muster löst dies, indem man die gesamte Erstellungslogik an einem Ort platziert. Wenn eine neue Zahlungsmethode eingeführt wird, fügen Sie einfach eine neue konkrete Klasse hinzu und aktualisieren die Factory-Methode. Der Rest Ihrer App bleibt unverändert.

Wie das Fabrikmuster funktioniert

Das Muster umfasst typischerweise drei Teilnehmer:

  • Product – Eine Schnittstelle oder abstrakte Klasse, die die Operationen definiert, die alle Zahlungsmethoden unterstützen müssen (z. B. , .
  • Konkrete Produkte – Klassen, die die Produktschnittstelle für jede spezifische Zahlungsmethode implementieren (z. B. , .
  • Creator (Factory) – Eine Klasse (oder Funktion), die eine Methode zum Erstellen von Produkten enthält. Die Methode akzeptiert einen Parameter (z. B. einen String oder eine Enum) und gibt das entsprechende konkrete Produkt zurück.

In mobilen Apps ist diese Fabrik oft ein Singleton- oder ein Dependency-injected-Service, was es einfach macht, Implementierungen während des Testens oder bei der Unterstützung verschiedener App-Konfigurationen auszutauschen.

Warum Zahlungsmethoden in mobilen Apps komplex sind

Bevor wir uns mit der Implementierung befassen, ist es hilfreich, die spezifischen Schwachstellen zu verstehen, die das Factory-Muster anspricht. Die Zahlungsabwicklung in mobilen Apps geht über den einfachen Aufruf einer API hinaus.

  • Mehrere SDKs und APIs – Jeder Zahlungsanbieter bietet seine eigene SDK- oder REST-API an. Die direkte Integration in Ihre Geschäftslogik schafft eine enge Kopplung.
  • Regionale und regulatorische Unterschiede – Eine in einem Land verfügbare Zahlungsmethode ist in einem anderen Land möglicherweise nicht zulässig.
  • Validierungsregeln – Kreditkarten erfordern Luhn-Checks und die Validierung des Ablaufdatums; digitale Wallets benötigen Token-Handling; lokale Methoden können spezifische Feldanforderungen durchsetzen.
  • Fehlerbehandlung und Fallbacks – Wenn eine Zahlung fehlschlägt, muss die App möglicherweise eine alternative Methode anbieten oder mit verschiedenen Parametern erneut versuchen. Eine zentralisierte Fabrik vereinfacht diese Logik.
  • Tests – Sie möchten bei Unit-Tests keine echten Zahlungsserver treffen. Das Factory-Muster ermöglicht es Ihnen, Schein-Zahlungsobjekte einfach einzufügen.
  • Dynamische Konfiguration – Viele Apps holen verfügbare Zahlungsmethoden von einem entfernten Server ab (z. B. von Directus). Die Fabrik kann diese Konfiguration so interpretieren, dass sie zur Laufzeit die richtigen Objekte erstellt.

Angesichts dieser Herausforderungen wird eine gut gestaltete Zahlungsabstraktion kritisch, und das Fabrikmuster bildet diese Abstraktionsebene.

Implementierung des Factory Pattern für Zahlungsmethoden

Lassen Sie uns eine konkrete Implementierung durchgehen. Während die Codebeispiele sprachunabhängig sind (Pseudocode), verwenden wir Konzepte, die direkt in Swift, Kotlin, Flutter oder React Native übersetzt werden.

Schritt 1: Definieren Sie die Zahlungsmethode-Schnittstelle

Beginnen Sie mit der Definition einer gemeinsamen Schnittstelle, die alle Zahlungsmethoden implementieren müssen, wobei diese Schnittstelle Methoden enthalten sollte, die für alle Zahlungsarten wie und universell sind.

interface PaymentMethod {
 func processPayment(amount: Double, currency: String) -> PaymentResult
 func validate() -> Bool
}

Sie können auch Eigenschaften wie , oder einschließen, die die Benutzeroberfläche verwenden kann, um Zahlungsoptionen anzuzeigen.

Schritt 2: Erstellen Sie konkrete Zahlungsklassen

Erstellen Sie für jede von Ihnen unterstützte Zahlungsmethode eine Klasse, die die -Schnittstelle implementiert.

class CreditCardPayment : PaymentMethod {
 private let cardNumber: String
 private let expiry: String
 private let cvv: String

 init(cardNumber: String, expiry: String, cvv: String) {
 self.cardNumber = cardNumber
 self.expiry = expiry
 self.cvv = cvv
 }

 func validate() -> Bool {
 // Luhn check, expiry date > today, etc.
 return true // simplified
 }

 func processPayment(amount: Double, currency: String) -> PaymentResult {
 // Call Stripe or Braintree SDK
 return PaymentResult.success()
 }
}

class PayPalPayment : PaymentMethod {
 private let token: String

 init(token: String) {
 self.token = token
 }

 func validate() -> Bool {
 return !token.isEmpty
 }

 func processPayment(amount: Double, currency: String) -> PaymentResult {
 // Call PayPal SDK
 return PaymentResult.success()
 }
}

class ApplePayPayment : PaymentMethod {
 private let paymentData: Data

 init(paymentData: Data) {
 self.paymentData = paymentData
 }

 func validate() -> Bool {
 return paymentData.count > 0
 }

 func processPayment(amount: Double, currency: String) -> PaymentResult {
 // Use PassKit or Stripe Apple Pay integration
 return PaymentResult.success()
 }
}

Beachten Sie, dass jede konkrete Klasse ihre eigene Validierung und SDK-Aufrufe abwickelt. Der Rest der App kümmert sich nicht um die Unterschiede - sie ruft nur auf.

Schritt 3: Bauen Sie die Factory Class

Die Factory-Klasse ist dafür verantwortlich, das entsprechende Zahlungsmethodeobjekt basierend auf Eingabeparametern zu erstellen, die von der Benutzerauswahl, einem Konfigurationsobjekt oder einer Serverantwort (z.B. von Directus) stammen können.

class PaymentFactory {

 static func createPaymentMethod(type: String, parameters: [String: Any]) -> PaymentMethod? {
 switch type {
 case "credit_card":
 guard let cardNumber = parameters["cardNumber"] as? String,
 let expiry = parameters["expiry"] as? String,
 let cvv = parameters["cvv"] as? String else {
 return nil
 }
 return CreditCardPayment(cardNumber: cardNumber, expiry: expiry, cvv: cvv)

 case "paypal":
 guard let token = parameters["token"] as? String else {
 return nil
 }
 return PayPalPayment(token: token)

 case "apple_pay":
 guard let paymentData = parameters["paymentData"] as? Data else {
 return nil
 }
 return ApplePayPayment(paymentData: paymentData)

 default:
 return nil
 }
 }
}

In einem fortgeschritteneren Szenario können Sie anstelle eines Strings für den Typ ein Enum verwenden oder die Factory-Konfiguration von einer entfernten Quelle laden.

Schritt 4: Verwenden der Factory in Ihrer App

Wenn ein Benutzer nun eine Zahlungsmethode auswählt und die erforderlichen Details bereitstellt, muss Ihr Ansichtsmodell oder Controller nur die Fabrik anrufen:

let paymentType = selectedPaymentMethod.type // "credit_card", "paypal", etc.
let parameters = collectInputParameters()
if let paymentMethod = PaymentFactory.createPaymentMethod(type: paymentType, parameters: parameters) {
 paymentMethod.processPayment(amount: total, currency: "USD")
} else {
 // show error – unsupported method or invalid input
}

Das Hinzufügen einer neuen Zahlungsmethode (z. B. Google Pay) erfordert nur eine neue Klasse und einen zusätzlichen Fall in der Fabrikerklärung [FLT: 17] - es sind keine weiteren Änderungen erforderlich.

Umgang mit Variationen: Länderspezifische und dynamische Fabriken

In realen Apps ändert sich die Anzahl der verfügbaren Zahlungsmethoden oft je nach Land des Benutzers, der App-Version oder den Geschäftsregeln.

Suppose you use Directus to store enabled payment methods per region. Your backend returns a JSON object like this:

{
 "methods": ["credit_card", "paypal", "apple_pay"],
 "paypal": { "environment": "sandbox", "clientId": "abc123" }
}

Diese Konfiguration können Sie in einem Repository oder im Zustand Ihrer App speichern.

class DynamicPaymentFactory {
 private let config: PaymentConfiguration

 init(config: PaymentConfiguration) {
 self.config = config
 }

 func createPaymentMethod(type: String, parameters: [String: Any]) -> PaymentMethod? {
 guard config.methods.contains(type) else { return nil }
 // Use config-specific parameters (e.g., clientId for PayPal)
 // ... switch as before
 }
}

Dieser Ansatz hält Ihre App anpassungsfähig, ohne dass für jeden Wechsel des Zahlungsanbieters eine neue App-Version erforderlich ist.

Vorteile der Verwendung des Factory Pattern

Inzwischen sollten die Vorteile klar sein. Lassen Sie uns sie gründlicher aufzählen.

1. Einkapselung der Objekterstellung

Die Factory zentralisiert die Instanziationslogik. Ändert sich der Konstruktor einer Zahlungsklasse (z.B. wird ein neuer erforderlicher Parameter hinzugefügt), aktualisieren Sie nur die Factory und die konkrete Klasse. Alle Anrufer bleiben unberührt.

2. Einhaltung des offenen/geschlossenen Grundsatzes

Ihr Code ist offen für Erweiterungen (das Hinzufügen neuer Zahlungsmethoden), aber geschlossen für Änderungen (bestehende Klassen ändern sich nicht), was das Risiko verringert, dass Fehler in bereits getestete Zahlungsströme eingeführt werden.

3. Vereinfachte Einzelprüfung

Da die Fabrik verspottet oder ersetzt werden kann, können Sie während des Testens einfach gefälschte Zahlungsobjekte einfügen. z. B. können Sie eine FLT:20 erstellen, die immer eine erfolgreiche Zahlung zurückgibt, ohne das Netzwerk zu berühren.

4. Verbesserte Code-Organisation

Das Fabrikmuster gruppiert naturgemäß verwandte Klassen (Zahlungsmethoden) unter einer gemeinsamen Schnittstelle, wodurch die Codebasis leichter zu navigieren und zu verstehen ist.

5. Laufzeitflexibilität

Sie können die Fabrik mit einem Strategie- oder Vorlagenmuster kombinieren, um das Verhalten basierend auf Laufzeitbedingungen zu ändern, z. B. die Wahl zwischen einer Test- und einer Produktionsumgebung.

6. Skalierbarkeit

Wenn Ihre App Dutzende von Zahlungsmethoden unterstützt, wird das Factory-Muster anmutig skaliert. Jede neue Methode ist eine separate Datei und der Factory-Switch bleibt linear.

Real-World Überlegungen

Integration mit Dependency Injection

In modernen mobilen Architekturen (MVVM, Clean Architecture, Viper) sollte die Fabrik in Ihrem Abhängigkeits-Injektionscontainer registriert werden. Auf diese Weise können Sie eine echte Fabrik in Produktion und eine Scheinfabrik in Tests injizieren.

// Swift with Swinject
container.register(PaymentFactoryProtocol.self) { _ in PaymentFactory() }

Fehlerbehandlung und Fallbacks

Ihre Fabrik sollte ungültige Eingaben anmutig behandeln. Wenn Sie zurückgeben oder einen bestimmten Fehlertyp werfen, kann der Anrufer eine aussagekräftige Benutzeroberfläche anzeigen. In ähnlicher Weise können Sie eine Fallback-Fabrik implementieren, die standardmäßig auf eine universelle Zahlungsmethode zurückgreift, wenn die angeforderte nicht initialisiert wird.

Konfiguration aus Backend (Directus)

Directus kann verwendet werden, um Metadaten von Zahlungsmethoden zu speichern, wie z. B. die Anzeigereihenfolge, erforderliche Felder oder sogar benutzerdefinierte Validierungsregeln. Ihre mobile App holt diese Konfiguration beim Start ab und leitet sie an die Fabrik weiter. Dies entkoppelt den Client von der hartcodierten Zahlungslogik.

Zum Beispiel könnten Sie eine -Sammlung in Directus mit Feldern erstellen:

  • (String: "credit card", "paypal")
  • [25] (Zeichenfolge)
  • (JSON-Feldnamen-Array)
  • [27] (Boulesche)

Ihre mobile App holt diese Sammlung über das Directus SDK ab und baut die Fabrikregistrierung dynamisch auf. Dieses Muster ermöglicht es Nicht-Entwickler-Stakeholdern, Zahlungsangebote ohne Codeänderungen zu steuern.

Best Practices bei der Verwendung des Factory Patterns

  • Behalte die Fabrik einfach. Es sollte nur Objekte erstellen. Wenn Sie Geschäftslogik hinzufügen (z. B. Währungsumrechnung), extrahieren Sie diese in separate Dienste.
  • Verwende starkes Tippen. Bevorzuge Enums oder versiegelte Klassen gegenüber Strings für den Methodentyp. Dies verhindert, dass Laufzeitfehler falsch geschriebene Identifikatoren haben und bietet Compiler-Unterstützung.
  • Dokumentation der Schnittstelle. Sicherstellen, dass alle Mitglieder der Schnittstelle klare Verträge haben.
  • Teste die Fabrik separat. Schreibe Unit-Tests, die überprüfen, dass die Fabrik die richtige konkrete Klasse für jede Eingabe zurückgibt, und dass sie für nicht unterstützte Typen null zurückgibt.
  • Kombiniere mit anderen Mustern. Die Fabrik funktioniert gut mit dem Strategiemuster (um verschiedene Zahlungsströme zu bewältigen) und dem Buildermuster (wenn eine Zahlungsmethode eine komplexe Konfiguration erfordert).
  • Betrachten Sie eine Registrierung. Statt eines monolithischen Switches können Sie eine offene Registrierung erstellen, in der sich Zahlungsmethodenklassen selbst registrieren.

Schlussfolgerung

Die Verwaltung mehrerer Zahlungsmethoden in mobilen Apps muss keine Quelle technischer Schulden sein. Durch die Anwendung des Factory-Musters können Sie die Komplexität der Objekterstellung einfangen, wodurch Ihre Codebasis sauberer, testbarer und bereit für zukünftige Erweiterungen wird. Das Muster respektiert das Open/Closed-Prinzip, entkoppelt die Geschäftslogik von SDKs von Drittanbietern und integriert sich reibungslos in moderne Architekturen und Backend-Dienste wie Directus.

Wenn Sie das nächste Mal auf eine wachsende Liste von Zahlungsoptionen stoßen, greifen Sie nach dem Fabrikmuster. Es spart Ihnen Zeit, reduziert Fehler und lässt Sie neue Zahlungsmethoden mit Zuversicht hinzufügen.

Weiterlesen:
- Factory Method Pattern (Wikipedia)
Stripe Payment Quickstart – mobile Integration
- Directus Collections and API Reference