Encapsulation

Intermediate ~25 min read

Encapsulation is the practice of bundling data and methods that operate on that data within a single class, while restricting direct access to some components. Python uses naming conventions (underscores) rather than strict access modifiers to indicate the intended visibility of attributes and methods.

Python's Access Levels

Prefix	Name	Meaning
`attr`	Public	Accessible from anywhere
`_attr`	Protected	Internal use, subclasses OK (convention)
`__attr`	Private	Name mangled to prevent accidental access

Public Attributes

Public attributes have no underscore prefix and can be freely accessed and modified from anywhere. They're part of the class's public interface.

# Public Attributes and Methods

print("=== Public Access ===\n")

# 1. Public attributes - accessible from anywhere
print("1. Public attributes (no prefix):")

class Person:
    def __init__(self, name, age):
        self.name = name  # Public attribute
        self.age = age    # Public attribute

def greet(self):  # Public method
        return f"Hello, I'm {self.name}!"

person = Person("Alice", 30)

# Directly access public attributes
print(f"   Name: {person.name}")
print(f"   Age: {person.age}")
print(f"   Greeting: {person.greet()}")

# Can modify directly
person.name = "Bob"
person.age = 25
print(f"   Modified: {person.name}, {person.age}")
print()

# 2. Problem with fully public attributes
print("2. The problem - no validation:")

class Temperature:
    def __init__(self, celsius):
        self.celsius = celsius  # Public, no validation

temp = Temperature(25)
print(f"   Initial: {temp.celsius}°C")

# Anyone can set invalid values!
temp.celsius = -500  # Below absolute zero!
print(f"   Invalid value allowed: {temp.celsius}°C")
print()

# 3. When public is OK
print("3. When public attributes are fine:")
print("""
   Public attributes are appropriate when:
   - Simple data container (like namedtuple replacement)
   - No validation needed
   - Value can be any valid type
   - Internal implementation detail doesn't matter

Example: Point(x, y), Rectangle(width, height)
""")

class Point:
    """Simple data container - public is fine."""
    def __init__(self, x, y):
        self.x = x
        self.y = y

def distance_from_origin(self):
        return (self.x ** 2 + self.y ** 2) ** 0.5

p = Point(3, 4)
print(f"   Point({p.x}, {p.y})")
print(f"   Distance: {p.distance_from_origin()}")

Output

Click Run to execute your code

Start Public, Encapsulate Later

Python philosophy: start with public attributes. Add encapsulation (underscore) when you actually need validation or computed values. Don't over-engineer prematurely.

Protected Attributes (_single underscore)

A single underscore prefix signals "this is internal, use at your own risk." It's a convention that Python developers respect, though it's not enforced by the language.

# Protected Attributes (Single Underscore)

print("=== Protected Access (_) ===\n")

# 1. Protected convention - single underscore prefix
print("1. Protected attributes (_prefix):")

class BankAccount:
    def __init__(self, owner, balance):
        self.owner = owner       # Public
        self._balance = balance  # Protected by convention
        self._account_type = "Savings"

def deposit(self, amount):
        if amount > 0:
            self._balance += amount
            return True
        return False

def get_info(self):
        return f"{self.owner}: ${self._balance} ({self._account_type})"

account = BankAccount("Alice", 1000)
print(f"   Info: {account.get_info()}")

# Protected attributes ARE accessible (just a convention)
print(f"   _balance: ${account._balance}")  # Works, but discouraged
print(f"   _account_type: {account._account_type}")  # Works, but discouraged
print()

# 2. Protected means "internal use"
print("2. Protected = 'use at your own risk':")
print("""
   The underscore says:
   - "This is an implementation detail"
   - "Don't rely on this in your code"
   - "May change without notice"
   - "Subclasses can use it"
""")

# 3. Protected in inheritance
print("3. Protected is useful in inheritance:")

class Vehicle:
    def __init__(self, brand):
        self._brand = brand   # Protected - subclasses can use
        self._speed = 0

def _accelerate(self, amount):
        """Protected method for subclasses."""
        self._speed += amount

class Car(Vehicle):
    def drive(self):
        self._accelerate(10)  # Subclass uses protected method
        return f"{self._brand} driving at {self._speed} mph"

car = Car("Toyota")
print(f"   {car.drive()}")
print(f"   {car.drive()}")
print()

# 4. Common protected patterns
print("4. Common uses of protected:")

class DatabaseConnection:
    def __init__(self, host):
        self._host = host
        self._connection = None
        self._is_connected = False

def connect(self):
        """Public interface."""
        self._establish_connection()

def _establish_connection(self):
        """Protected - implementation detail."""
        print(f"   Connecting to {self._host}...")
        self._connection = f"Connection to {self._host}"
        self._is_connected = True
        print(f"   Connected!")

def _validate_connection(self):
        """Protected helper method."""
        if not self._is_connected:
            raise Exception("Not connected!")

db = DatabaseConnection("localhost")
db.connect()
print()

# 5. Tools respect the convention
print("5. IDEs and tools recognize underscore:")
print("""
   - IDEs won't autocomplete _attributes by default
   - Linters may warn about accessing _attributes
   - Documentation tools may hide _methods
   - It's a social contract, not enforcement
""")

Output

Click Run to execute your code

It's a Convention, Not Enforcement

Python won't stop you from accessing _protected attributes. The underscore is a signal to other developers: "this is an implementation detail that may change." Respect the convention in your own code.

Private Attributes (__double underscore)

Double underscore prefix triggers "name mangling" - Python renames the attribute to include the class name, making accidental access harder. Use this to prevent subclass attribute conflicts.

# Private Attributes (Double Underscore)

print("=== Private Access (__) ===\n")

# 1. Private with double underscore
print("1. Private attributes (__prefix):")

class SecureAccount:
    def __init__(self, owner, pin, balance):
        self.owner = owner        # Public
        self.__pin = pin          # Private
        self.__balance = balance  # Private

def verify_pin(self, pin):
        """Only way to use the private __pin."""
        return pin == self.__pin

def get_balance(self, pin):
        """Access private data after verification."""
        if self.verify_pin(pin):
            return self.__balance
        return "Access denied"

account = SecureAccount("Alice", "1234", 5000)
print(f"   Owner: {account.owner}")
print(f"   Correct PIN: {account.get_balance('1234')}")
print(f"   Wrong PIN: {account.get_balance('0000')}")

# Try to access private attribute directly
try:
    print(account.__balance)
except AttributeError as e:
    print(f"   Direct access failed: {e}")
print()

# 2. Name Mangling explained
print("2. Name Mangling (Python's 'privacy'):")

class Demo:
    def __init__(self):
        self.__secret = "hidden"

d = Demo()

# Python renames __secret to _Demo__secret
print(f"   __dict__: {d.__dict__}")
print(f"   _Demo__secret: {d._Demo__secret}")  # This works!
print()
print("   Python doesn't truly hide private attributes!")
print("   It just renames them: __attr -> _ClassName__attr")
print()

# 3. Why use double underscore?
print("3. Main use: Prevent subclass conflicts:")

class Parent:
    def __init__(self):
        self.__value = "parent"  # Won't clash with child

def get_value(self):
        return self.__value

class Child(Parent):
    def __init__(self):
        super().__init__()
        self.__value = "child"  # Different attribute!

def get_child_value(self):
        return self.__value

c = Child()
print(f"   Parent's value: {c.get_value()}")      # "parent"
print(f"   Child's value: {c.get_child_value()}")  # "child"
print(f"   __dict__: {c.__dict__}")
print()

# 4. When to use which?
print("4. Guidelines for access levels:")
print("""
   Public (no prefix):
   - Part of the class's public API
   - Users should use this

Protected (_single):
   - Implementation detail
   - Subclasses may need it
   - Most "private" attributes should use this

Private (__double):
   - Prevent accidental override in subclasses
   - Rare! Usually _single is enough
""")

# 5. Practical example
print("5. Practical example:")

class CreditCard:
    def __init__(self, number, cvv):
        self._number = number  # Protected - for internal use
        self.__cvv = cvv       # Private - extra protection

def get_masked_number(self):
        """Public method to show masked number."""
        return f"****-****-****-{self._number[-4:]}"

def _validate_transaction(self, amount):
        """Protected - used by subclasses."""
        return amount > 0

def __verify_cvv(self, cvv):
        """Private - internal verification only."""
        return cvv == self.__cvv

def make_purchase(self, amount, cvv):
        """Public interface."""
        if self.__verify_cvv(cvv) and self._validate_transaction(amount):
            return f"Purchased ${amount}"
        return "Transaction failed"

card = CreditCard("1234567890123456", "999")
print(f"   Card: {card.get_masked_number()}")
print(f"   Purchase: {card.make_purchase(50, '999')}")
print(f"   Wrong CVV: {card.make_purchase(50, '000')}")

Output

Click Run to execute your code

Name Mangling: __attr becomes _ClassName__attr

Python doesn't truly hide private attributes. It renames __secret to _MyClass__secret. This prevents accidental name clashes in inheritance, but determined users can still access it. Privacy in Python is about intent, not enforcement.

Getter and Setter Methods

To control access to attributes, provide getter and setter methods. These allow validation, computed values, and read-only attributes.

# Getter and Setter Methods

print("=== Getters and Setters ===\n")

# 1. Why use getters/setters?
print("1. The problem with direct access:")

class TemperatureBad:
    def __init__(self, celsius):
        self.celsius = celsius  # No validation

temp = TemperatureBad(25)
temp.celsius = -500  # Invalid! Below absolute zero
print(f"   Bad: celsius set to {temp.celsius}°C (invalid!)")
print()

# 2. Solution: Getter and setter methods
print("2. Getter and setter methods:")

class Temperature:
    def __init__(self, celsius):
        self._celsius = None
        self.set_celsius(celsius)  # Use setter for validation

def get_celsius(self):
        """Getter method."""
        return self._celsius

def set_celsius(self, value):
        """Setter method with validation."""
        if value < -273.15:
            raise ValueError("Temperature below absolute zero!")
        self._celsius = value

def get_fahrenheit(self):
        """Computed getter."""
        return self._celsius * 9/5 + 32

temp = Temperature(25)
print(f"   Celsius: {temp.get_celsius()}")
print(f"   Fahrenheit: {temp.get_fahrenheit()}")

temp.set_celsius(100)
print(f"   After set_celsius(100): {temp.get_celsius()}°C")

try:
    temp.set_celsius(-300)
except ValueError as e:
    print(f"   Validation error: {e}")
print()

# 3. Encapsulation benefits
print("3. Benefits of getters/setters:")

class BankAccount:
    def __init__(self, balance):
        self._balance = balance
        self._transactions = []

def get_balance(self):
        """Read-only access to balance."""
        return self._balance

def deposit(self, amount):
        """Controlled way to modify balance."""
        if amount <= 0:
            raise ValueError("Amount must be positive")
        self._balance += amount
        self._transactions.append(f"+${amount}")
        return self._balance

def withdraw(self, amount):
        """Validation before modification."""
        if amount <= 0:
            raise ValueError("Amount must be positive")
        if amount > self._balance:
            raise ValueError("Insufficient funds")
        self._balance -= amount
        self._transactions.append(f"-${amount}")
        return self._balance

def get_transactions(self):
        """Return copy to prevent modification."""
        return self._transactions.copy()

account = BankAccount(1000)
print(f"   Balance: ${account.get_balance()}")
account.deposit(500)
account.withdraw(200)
print(f"   After transactions: ${account.get_balance()}")
print(f"   Transaction log: {account.get_transactions()}")
print()

# 4. Read-only attributes
print("4. Read-only with getter only:")

class Employee:
    _next_id = 1

def __init__(self, name):
        self._id = Employee._next_id
        Employee._next_id += 1
        self._name = name

def get_id(self):
        """Read-only - no setter provided."""
        return self._id

def get_name(self):
        return self._name

def set_name(self, name):
        """Name can be changed."""
        self._name = name

emp = Employee("Alice")
print(f"   Employee ID: {emp.get_id()} (read-only)")
print(f"   Name: {emp.get_name()}")
emp.set_name("Alicia")
print(f"   Name changed to: {emp.get_name()}")
# emp.set_id(999)  # No such method - ID is read-only
print()

# 5. Note: Python has @property
print("5. Preview: Python has a better way!")
print("""
   Instead of explicit getters/setters:

class Temperature:
       @property
       def celsius(self):
           return self._celsius

@celsius.setter
       def celsius(self, value):
           if value < -273.15:
               raise ValueError("Too cold!")
           self._celsius = value

# Use like an attribute:
   temp.celsius = 25  # Calls setter
   print(temp.celsius)  # Calls getter

Learn more in the Properties lesson!
""")

Output

Click Run to execute your code

Python Has a Better Way: @property

Instead of explicit get_x() and set_x() methods, Python provides the @property decorator for cleaner syntax. You'll learn this in the Properties lesson.

Common Mistakes

1. Confusing _ and __ purposes

# Wrong - using __ just for "privacy"
class User:
    def __init__(self, name):
        self.__name = name  # Overkill! Use single underscore

# Better - single underscore for internal attributes
class User:
    def __init__(self, name):
        self._name = name  # Convention: internal use

# Use __ only to prevent subclass conflicts

2. Accessing private via name mangling

# Bad practice - bypassing name mangling
class Secret:
    def __init__(self):
        self.__value = 42

s = Secret()
print(s._Secret__value)  # Works but DON'T DO THIS!

# If you need to access it, the class should provide a method
# Or reconsider your design

3. Forgetting validation in setters

# Pointless getter/setter - no validation
class Person:
    def __init__(self, age):
        self._age = age

    def get_age(self):
        return self._age

    def set_age(self, age):
        self._age = age  # No validation! Why have a setter?

# Better - setter should validate
class Person:
    def set_age(self, age):
        if age < 0 or age > 150:
            raise ValueError("Invalid age")
        self._age = age

4. Returning mutable internal data

# Wrong - exposing internal list
class ShoppingCart:
    def __init__(self):
        self._items = []

    def get_items(self):
        return self._items  # Caller can modify!

cart = ShoppingCart()
items = cart.get_items()
items.append("hacked!")  # Modifies internal state!

# Correct - return a copy
def get_items(self):
    return self._items.copy()  # Safe copy

5. Over-encapsulating simple data classes

# Over-engineered for simple data
class Point:
    def __init__(self, x, y):
        self._x = x
        self._y = y

    def get_x(self): return self._x
    def get_y(self): return self._y
    def set_x(self, x): self._x = x
    def set_y(self, y): self._y = y

# Better - just use public attributes for simple data
class Point:
    def __init__(self, x, y):
        self.x = x  # Simple, direct
        self.y = y

Exercise: Secure User Account

Task: Create a User class with proper encapsulation for sensitive data.

Requirements:

Public: username - visible to everyone
Protected: _email - internal use with getter
Private: __password - never exposed directly
Methods: verify_password(), change_password()
__str__: Show username and masked email

Output

Click Run to execute your code

Show Solution

class User:
    def __init__(self, username, email, password):
        self.username = username      # Public
        self._email = email           # Protected
        self.__password = password    # Private

    def get_email(self):
        return self._email

    def verify_password(self, password):
        return password == self.__password

    def change_password(self, old_password, new_password):
        if self.verify_password(old_password):
            self.__password = new_password
            return True
        return False

    def __str__(self):
        # Mask email: first char + *** + @domain
        parts = self._email.split('@')
        masked = parts[0][0] + '***@' + parts[1]
        return f"User: {self.username}, Email: {masked}"


# Test
user = User("alice", "[email protected]", "secret123")
print(user.username)  # alice
print(user.get_email())  # [email protected]
print(user.verify_password("secret123"))  # True
print(user.verify_password("wrong"))  # False
print(user.change_password("secret123", "newpass"))  # True
print(user)  # User: alice, Email: a***@example.com

Summary

Public (no prefix): Accessible from anywhere, part of public API
Protected (_single): Convention for internal use, subclasses OK
Private (__double): Name mangled to prevent subclass conflicts
Name mangling: __attr becomes _ClassName__attr
Getters/setters: Methods for controlled access and validation
Python relies on conventions, not enforcement - "we're all consenting adults"

What's Next?

Now that you understand encapsulation, learn about Polymorphism - how different classes can share the same interface, enabling flexible and reusable code through duck typing and method overriding.

Previous Inheritance

Next Polymorphism

Python's Access Levels

Public Attributes

Start Public, Encapsulate Later

Protected Attributes (_single underscore)

It's a Convention, Not Enforcement

Private Attributes (__double underscore)

Name Mangling: __attr becomes _ClassName__attr

Getter and Setter Methods

Python Has a Better Way: @property

Common Mistakes

1. Confusing _ and __ purposes

2. Accessing private via name mangling

3. Forgetting validation in setters

4. Returning mutable internal data

5. Over-encapsulating simple data classes

Exercise: Secure User Account

Summary

What's Next?

Enjoying these tutorials?