Applying Abstraction: Parking Lot Payment System

Consider designing a parking lot that accepts multiple payment methods. Abstraction allows the ParkingLot to process payments without knowing specific payment implementation details.
«interface»
PaymentMethod
+ authorize(amount): Boolean
+ charge(amount): PaymentResult
+ refund(transactionId): Boolean
▲
CreditCard
- cardNumber
- cvv
+ authorize()
+ charge()
+ refund()
MobileWallet
- phoneNumber
- appToken
+ authorize()
+ charge()
+ refund()
Cash
- amountTendered
+ authorize()
+ charge()
+ refund()
ParkingTransaction
- ticket: ParkingTicket
- paymentMethod: PaymentMethod
- amount: Money
+ processPayment(): Boolean
+ issueReceipt(): Receipt
Design Decision Rationale:
First, the PaymentMethod interface abstracts payment processing. The ParkingTransaction depends on the interface, not concrete implementations. This follows the Dependency Inversion Principle (DIP), where high-level modules depend on abstractions.
Second, each payment type implements the interface differently. CreditCard communicates with a payment gateway, MobileWallet uses OAuth tokens, and Cash simply validates the tendered amount. The ParkingTransaction remains unchanged when adding new payment methods like cryptocurrency or gift cards.
Third, the interface defines a complete contract with authorize(), charge(), and refund(). This ensures all payment methods support the full payment lifecycle. If a payment type does not support refunds (like some prepaid cards), it should throw an UnsupportedOperationException rather than silently fail, but this is a design trade-off discussed in advanced scenarios.
Machine Coding Consideration: In a 60-minute interview, start with 2-3 payment types. Demonstrate polymorphism by processing payments through the PaymentMethod interface. Interviewers value seeing proper abstraction over implementing every payment detail.

💡 Key Takeaways

✓PaymentMethod interface allows ParkingTransaction to process payments without knowing implementation details

✓Each payment type (CreditCard, MobileWallet, Cash) implements the interface contract differently

✓Adding new payment methods requires no changes to ParkingTransaction (Open/Closed Principle)

✓Interface defines complete contract including authorize, charge, and refund operations

📌 Examples

1ParkingTransaction processes CreditCard payment via gateway API without knowing API details

2Adding Bitcoin payment requires only new BitcoinPayment class implementing PaymentMethod interface

← Back to Abstraction & Interfaces Overview