Interfaces and Abstract Classes: Complete Beginner's Guide

An interface is a pure contract: it declares which methods a class must provide without saying how they work. An abstract class is a halfway house — it can provide some implemented methods while leaving others abstract (declared but not implemented) for children to fill in. Both let you program against promises rather than concrete classes.

They matter because real systems have multiple ways of doing the same job: UPI, cards and wallets all "process payments" differently. If checkout code depends on a PaymentProcessor interface instead of any specific processor, adding a brand-new payment method means writing one new class — zero changes to checkout. That is how professional software stays open for extension but closed for modification.

Key Concepts

• Interface: a set of method signatures with no implementation (Java's interface, Python's abstract base classes used purely, TypeScript interfaces, Go interfaces). A class implements it by providing every method.
• Abstract class: a class that cannot be instantiated and may mix concrete methods with abstract ones. Children extend it and must implement the abstract methods.
• Multiple interfaces, single inheritance: a class can implement many interfaces but extend only one class — interfaces are how languages without multiple inheritance stay flexible.
• Programming to an interface: writing code that uses only the interface's methods, so any implementation can be substituted.
• Abstract method: a method with a signature but no body, forcing every concrete child to supply its own version.

How It Works

• Define the contract: declare a PaymentProcessor interface with one method, pay(amount), returning success or failure.
• Implement variants: write UPIProcessor, CardProcessor and WalletProcessor classes, each implementing pay(amount) with its own gateway logic and fee rules.
• Depend on the contract: the Checkout class holds a PaymentProcessor reference, never a concrete class, and simply calls processor.pay(total).
• Extend freely: when the business adds net-banking, one new class implementing the interface plugs in; Checkout, receipts and refunds work unchanged because they never knew the concrete types.

Worked Example

An order totals ₹10,000. Three processors implement the same PaymentProcessor interface but charge different fees. Compute what the customer pays through each.

1. UPIProcessor: fee 0% → fee = 10,000 × 0 = ₹0 → customer pays ₹10,000.
2. CardProcessor: fee 2% → fee = 10,000 × 0.02 = ₹200 → customer pays ₹10,200.
3. WalletProcessor: fee 1.5% → fee = 10,000 × 0.015 = ₹150 → customer pays ₹10,150.
4. The checkout code calls the identical pay(10000) method in all three cases — the interface guarantees the call works, while polymorphism picks each processor's own fee logic.
5. Savings check: choosing UPI over card saves ₹200 on this order, which is exactly why the fee abstraction belongs in each processor, not in checkout.

Common Misconceptions

• "Interfaces and abstract classes are interchangeable." Use an interface for a pure capability contract (especially when unrelated classes share it); use an abstract class when children genuinely share code and an is-a relationship, like a Shape class with a concrete describe() method.
• "Interfaces are only a Java thing." Python has abstract base classes and Protocols, TypeScript has interfaces, Go's entire polymorphism model is interfaces, and even C has the same idea via function-pointer tables.
• "Every class needs an interface." Interfaces pay off where multiple implementations exist or are likely. Wrapping a single, stable class in an interface adds indirection with no benefit.

Real-World Applications

• Payment gateways: e-commerce platforms plug Razorpay, Stripe or Paytm behind one payment interface.
• Database drivers: Java's JDBC and Python's DB-API are interfaces; swapping MySQL for PostgreSQL changes the driver, not the app code.
• Plugins: editors and browsers define extension interfaces so third-party plugins integrate safely.
• Testing: mock objects implement the same interfaces as real services, letting tests run without networks or databases.

Interfaces declare what is promised, abstract classes share how part of it is done. Depend on contracts, implement them in as many ways as the business needs, and your core logic will welcome new variants without ever being rewritten.