Python Tutorials

Python Encapsulation : Public, Protected & Private Attributes

9 min read

Think about how you use a microwave. You press a few buttons on the front panel, and your food gets hot. You do not need to open the back of the microwave, manually reroute the electrical wires, or directly interact with the magnetron tube. In fact, the manufacturer deliberately seals those internal components inside a metal box to prevent you from touching them, because doing so could break the machine—or harm you!

In Object-Oriented Programming (OOP), Encapsulation is the exact same concept. When we build complex software, we want to seal the delicate, internal data of our objects away from the outside world. We only allow other programmers to interact with our objects through safe, predefined “buttons” (methods).

By mastering public, protected, and private attributes, you learn how to protect your object’s internal state from being accidentally corrupted by other parts of your code.

What is Encapsulation?

Encapsulation is one of the core pillars of Object-Oriented Programming. It refers to the bundling of data (attributes) and the methods that operate on that data into a single unit (a class). Furthermore, it restricts direct, unauthorized access to some of the object’s internal components.

Unlike languages like Java or C++, Python does not have strict access modifier keywords like public or private. Instead, Python relies on a strict naming convention using underscores to indicate how an attribute should be treated by other developers.

Syntax & Basic Usage

In Python, the level of privacy for an attribute or method is determined purely by how many underscores you put in front of its name.

  • Public (self.name): No underscores. Accessible from anywhere.
  • Protected (self._name): One underscore. A warning to other developers that this is for internal use only.
  • Private (self.__name): Two underscores. Triggers “name mangling” to actively prevent accidental access from outside the class.
class SmartDevice:
    def __init__(self):
        # 1. PUBLIC: Anyone can view or change this safely
        self.device_name = "Living Room Thermostat"
        
        # 2. PROTECTED: "Please don't touch this unless you know what you are doing"
        self._firmware_version = "v1.4.2"
        
        # 3. PRIVATE: "Strictly hidden. Do not touch from the outside!"
        self.__admin_password = "SuperSecretPassword123"

# Instantiating the object
home_thermostat = SmartDevice()

# Accessing the public attribute is perfectly fine
print(f"Device: {home_thermostat.device_name}")

# Expected Output:
# Device: Living Room Thermostat

Python Encapsulation Methods and Function Arguments

To become a senior Python developer, you must understand exactly how Python enforces—or politely suggests—these privacy levels, and how to safely access private data when necessary.

1. Public Attributes (The Default)

By default, every attribute and method in a Python class is public. You can read them, overwrite them, and even delete them from completely outside the class.

class CoffeeMachine:
    def __init__(self):
        # Public attribute
        self.water_level = 100

office_machine = CoffeeMachine()

# Reading a public attribute directly
print(f"Starting water level: {office_machine.water_level}%")

# Overwriting a public attribute directly from the outside
office_machine.water_level = 5000 # Wait, a coffee machine can't hold 5000% water!
print(f"Corrupted water level: {office_machine.water_level}%")

# Expected Output:
# Starting water level: 100%
# Corrupted water level: 5000%

Note: Because water_level is public, we accidentally corrupted our machine’s logic by assigning an impossible value to it.

2. Protected Attributes (The Single Underscore _)

To solve the issue above, we can mark an attribute as Protected using a single leading underscore (e.g., _water_level).

Crucial Concept: Python does not technically stop you from accessing a protected variable. It is a “gentleman’s agreement” among Python developers. When another developer sees the _, they know: “This is internal data. I should not touch it directly, otherwise I might break the class.”

class CoffeeMachine:
    def __init__(self):
        # Protected attribute: The underscore signals "Internal Use Only"
        self._water_level = 100

office_machine = CoffeeMachine()

# Python will STILL let you do this, but it is considered terrible practice!
office_machine._water_level = 5000 
print(f"Rule broken. Water level: {office_machine._water_level}%")

# Expected Output:
# Rule broken. Water level: 5000%

3. Private Attributes (The Double Underscore __)

If you want to actively stop someone from accidentally accessing an attribute, you make it Private using a double leading underscore (e.g., __water_level).

When Python sees __, it performs Name Mangling. It secretly changes the name of the variable behind the scenes so that it cannot be easily referenced by its original name from outside the class.

class SecureVault:
    def __init__(self):
        # Private attribute: Double underscore triggers name mangling
        self.__vault_password = "OpenSesame!"

corporate_vault = SecureVault()

try:
    # Attempting to access the private variable directly from the outside
    print(corporate_vault.__vault_password)
except AttributeError as e:
    print(f"Access Denied! Error: {e}")

# Expected Output:
# Access Denied! Error: 'SecureVault' object has no attribute '__vault_password'

4. Bypassing Name Mangling (The Secret Key)

Python’s philosophy is “We are all consenting adults here.” It hides private variables to prevent accidents, but it doesn’t stop malicious intent. You can still access a mangled private variable if you know its secret, mangled name: _ClassName__AttributeName.

class SecureVault:
    def __init__(self):
        self.__vault_password = "OpenSesame!"

corporate_vault = SecureVault()

# Bypassing the privacy by using the mangled name (Terrible practice!)
hacked_password = corporate_vault._SecureVault__vault_password

print(f"Hacked Private Data: {hacked_password}")

# Expected Output:
# Hacked Private Data: OpenSesame!

5. Getters and Setters (The Safe Interface)

If an attribute is private, how do we safely change it? We provide Getters (methods to read the data) and Setters (methods to change the data). This allows us to put validation logic inside the setter, ensuring no one can corrupt the object’s state!

class UserProfile:
    def __init__(self, username):
        self.username = username
        # Private attribute
        self.__age = 0 

    # GETTER Method: Safely returns the private data
    def get_age(self):
        return self.__age

    # SETTER Method: Safely updates the private data, with validation!
    def set_age(self, new_age):
        if type(new_age) != int:
            print("Error: Age must be a number.")
        elif new_age < 0 or new_age > 120:
            print(f"Error: {new_age} is an invalid age.")
        else:
            self.__age = new_age
            print(f"Age successfully updated to {self.__age}.")

new_user = UserProfile("Alice")

# Trying to pass bad data through our safe Setter "button"
new_user.set_age("Twenty")
new_user.set_age(-5)

# Passing good data
new_user.set_age(28)

# Reading the data safely through the Getter
print(f"Verified Age: {new_user.get_age()}")

# Expected Output:
# Error: Age must be a number.
# Error: -5 is an invalid age.
# Age successfully updated to 28.
# Verified Age: 28


Code language: HTML, XML (xml)

Real-World Practical Examples

Scenario 1: A Secure Bank Account

In financial software, allowing direct access to a user’s account balance is a massive security vulnerability. We must encapsulate the balance and force all interactions through deposit and withdraw methods.

class BankAccount:
    def __init__(self, owner_name, starting_balance):
        self.owner = owner_name
        # The balance is strictly private
        self.__balance = starting_balance
        
    def get_balance(self):
        # A read-only getter. Notice there is no 'set_balance' method at all!
        # This makes the balance effectively Read-Only from the outside.
        return self.__balance
        
    def deposit(self, amount):
        if amount > 0:
            self.__balance += amount
            print(f"Deposited ${amount}. New balance: ${self.__balance}")
        else:
            print("Deposit failed: Amount must be positive.")
            
    def withdraw(self, amount):
        if 0 < amount <= self.__balance:
            self.__balance -= amount
            print(f"Withdrew ${amount}. Remaining balance: ${self.__balance}")
        else:
            print("Withdrawal failed: Insufficient funds or invalid amount.")

# Using the encapsulated bank account
my_account = BankAccount("David", 500)

my_account.deposit(200)
my_account.withdraw(1000) # Fails safely!

# Accessing the read-only balance
print(f"Final Balance: ${my_account.get_balance()}")

# Expected Output:
# Deposited $200. New balance: $700
# Withdrawal failed: Insufficient funds or invalid amount.
# Final Balance: $700

Scenario 2: Employee ID Generation

Sometimes a class manages internal data that the user shouldn’t even know exists. Here, the company’s internal ID counter is private and protected from manipulation.

class Employee:
    # Private class attribute. Cannot be altered from the outside.
    __next_id_number = 1001 
    
    def __init__(self, name, department):
        self.name = name
        self.department = department
        
        # Assign the current internal ID, then safely increment it for the next employee
        self.__employee_id = Employee.__next_id_number
        Employee.__next_id_number += 1
        
    def get_employee_info(self):
        return f"[{self.__employee_id}] {self.name} - {self.department}"

# Hiring employees
emp1 = Employee("Sarah", "Engineering")
emp2 = Employee("Marcus", "Sales")

print(emp1.get_employee_info())
print(emp2.get_employee_info())

# Attempting to tamper with the internal ID counter fails
try:
    print(Employee.__next_id_number)
except AttributeError:
    print("Cannot tamper with the internal company ID counter!")

# Expected Output:
# [1001] Sarah - Engineering
# [1002] Marcus - Sales
# Cannot tamper with the internal company ID counter!

Best Practices & Common Pitfalls

  • Don’t Over-Encapsulate: Unlike Java, where every variable is forced to be private and requires getters/setters, Python prefers simplicity. If a variable doesn’t require complex validation (like a user’s first_name), just leave it Public. Only use private attributes when you explicitly need to protect the data from corruption.
  • The “Consenting Adults” Philosophy: Remember that _ (Protected) and __ (Private) are primarily conventions. Python trusts developers not to intentionally sabotage the code by accessing mangled names (e.g., _Class__private_var). If you try to build impenetrable military-grade security using just double underscores, you misunderstand Python’s design. It is meant to prevent accidents, not malicious hacking.
  • Using @property (Advanced): While we used standard getter and setter methods (get_age() and set_age()) above to clearly demonstrate the concept, advanced Python developers often use the @property decorator. This allows you to write setter validation logic but lets the user interact with the variable as if it were a normal public attribute (e.g., user.age = 25).

Summary

  • Encapsulation is the practice of bundling data and methods into a class, and hiding the internal, sensitive data from the outside world.
  • Public Attributes (self.name) are accessible and modifiable from anywhere.
  • Protected Attributes (self._name) use a single underscore to signal to other developers that the variable is intended for internal use only.
  • Private Attributes (self.__name) use a double underscore to trigger Name Mangling, actively raising an error if accessed directly from outside the class.
  • To safely interact with private attributes, we create Getters (methods that return the data) and Setters (methods that validate input before updating the data).

Leave a Comment