Encapsulation and abstraction

Hiding the wiring

When you use a phone you press a few buttons; you do not touch the circuits inside. That split, a simple surface over a protected interior, is what these two ideas give your objects. Encapsulation keeps an object's data tucked behind its methods so nothing outside can quietly corrupt it. Abstraction goes further and lets you describe what a kind of object must be able to do while leaving the how to each specific object. Both make programs easier to trust and easier to change.

Public, protected and private

Python marks how freely an attribute is meant to be touched using underscores in its name. There are three levels by convention.

• A plain name like balance is public: anyone may read or change it.
• A single leading underscore, _balance, marks it protected: a polite sign meaning "internal, please do not touch from outside". Python does not stop you, but you have been warned.
• A double leading underscore, __balance, is private: Python actively mangles the name so that code outside the class cannot reach it by the obvious path.

class GiftCard:
    def __init__(self, amount):
        self.__balance = amount        # private: kept inside the class

    def get_balance(self):
        return self.__balance

    def spend(self, amount):
        if 0 < amount <= self.__balance:
            self.__balance = self.__balance - amount
        else:
            print("Invalid amount")

card = GiftCard(50)
card.spend(20)
print(card.get_balance())    # 30
print(card.__balance)        # AttributeError: no such attribute

The last line fails on purpose. Because __balance is private, the outside world cannot poke it directly and set the card to a silly value. The only way in is through spend, which checks the amount first.

Getters, setters and why they guard

Private data is reached through getter and setter methods, exactly as you met earlier. The reason to force everything through them is control. spend is really a guarded setter: it refuses an amount that is negative or larger than the balance, so the card can never fall into an impossible state. If the balance were public, any stray line anywhere could set it to a negative number and nobody would notice until much later.

from abc import ABC, abstractmethod

class PaymentMethod(ABC):
    @abstractmethod
    def pay(self, amount):
        pass                       # no body: each child must supply one


class CardPayment(PaymentMethod):
    def pay(self, amount):
        return f"Charged {amount} to the card"


class CashPayment(PaymentMethod):
    def pay(self, amount):
        return f"Took {amount} in cash"

for method in (CardPayment(), CashPayment()):
    print(method.pay(30))

# Charged 30 to the card
# Took 30 in cash

Encapsulation hides the inside so data stays safe; abstraction fixes the outside so every family member honours the same contract. Together they let you build large programs out of parts you can trust without reading their insides.

Prefer to see it explained? Here is the recorded Code for Albania lecture on this topic.

Check yourself

1. What is the practical difference between a single underscore _name and a double underscore __name, and which one does Python actually enforce?
2. The spend method refuses a negative or oversized amount. Explain how making __balance private, rather than public, is what makes that guard meaningful.
3. PaymentMethod is an abstract base class with an abstract pay method. What two things does marking it that way prevent, and why is that useful when other people write new payment types?