Encapsulation, Properties, and Class Variables

Let's start with the big problem: what happens when you have a piece of data inside an object that you absolutely must protect from being changed incorrectly? Without protection, any part of your code could accidentally assign an invalid value, like setting a person's age to 'banana' or a bank account balance to a negative number. Encapsulation is the solution to this chaos.

Encapsulation, at its core, is the principle of bundling the data (attributes, also called variables) and the methods (functions) that operate on that data into a single unit, a class, and then restricting direct access to some of that data. Think of it as the protective shell around an object's internal state. The goal is to prevent the internal representation of an object from being directly exposed and modified from outside.

Python achieves this through naming conventions, not strict privacy like some other languages. To make an attribute 'private', you prefix its name with two underscores: __. For example, self.__balance. This triggers a feature called name mangling. When Python sees this, it internally renames the attribute to _ClassName__balance. This makes it harder to accidentally access from outside the class, though it is not completely impossible. A 'protected' attribute uses a single underscore: _protected_value. This is a convention that says, "This is internal to the class and its subclasses; please do not touch it from outside."

Where encapsulation really shines is when you combine it with properties. A property is a Python feature that lets you define methods that look like simple attribute access from the outside. You decorate a method with @property to make it a getter, and with @<attribute_name>.setter to make it a setter. This means you can have a method that runs validation logic every time someone tries to assign a value to an attribute, but the code using your object just does object.attribute = value.

Here is how it works step by step:

This approach replaces the older, clunkier style of writing explicit get_age() and set_age(value) methods, which made client code look messy. Properties allow you to start with direct attribute access and later add validation logic without changing any of the code that uses your class. That is a huge advantage.

Now, let us talk about class variables. These are variables that belong to the class itself, not to any single instance (object) of the class. You define them directly inside the class body, outside of any method. For example:

class Employee: company_name = "Courseiva" employee_count = 0

Every Employee object shares the same company_name. If you change Employee.company_name, every instance sees the change. This is perfect for storing data that should be the same across all instances, like a default value or a running count of how many objects have been created. Instance variables, in contrast, are defined inside __init__ using self.attribute = value and are unique to each object.

Class methods and static methods are the final pieces of this puzzle. A class method is a method that receives the class itself as its first argument (conventionally named cls), not an instance. You create it with the @classmethod decorator. You use class methods when you need to operate on class-level data or provide an alternative constructor. For example, a class method from_string(cls, data_string) could parse a string and return a new instance of the class.

A static method, decorated with @staticmethod, does not receive self or cls as its first argument. It is essentially a regular function that lives inside the class namespace because it logically belongs there. You use it for utility functions that perform a task related to the class but do not need access to any instance or class data, like converting a number from one unit to another.

Together, these tools let you design classes that are self-contained, safe from accidental misuse, and clear in their purpose. You hide the guts of the data (encapsulation), you control how data is read and written (properties), you share data across all objects cleanly (class variables), and you organise functions that belong to the class logically (class and static methods).

Imagine you are a junior developer at a travel booking company, and your first task is to build a Python class to represent a customer booking. The system will be used by your team and later by a mobile app. You need to ensure that nobody can accidentally set a booking's price to a negative number or assign an invalid date. This is where the concepts of encapsulation and properties become your best friends.

You start by defining a Booking class. Your first instinct might be to just use public attributes: booking.price = 49.99. But you quickly realise the danger: what if some code later does booking.price = -100? That would be a disaster for accounting. So, you use the @property decorator to build a controlled interface.

Here is your step-by-step workflow as an IT professional:

This means the accounting team can write booking.price = 199.99 and it will work, but booking.price = -50 will immediately throw an error, preventing corrupted data. You have effectively encapsulated the price attribute and added a validation gate.

Next, your manager asks you to track the total number of active bookings across the entire system. You cannot store this in a single booking instance because it needs to be shared. The solution is a class variable. You add:

class Booking: total_active_bookings = 0

Then, inside the __init__ method, you increment it by one: Booking.total_active_bookings += 1. When a booking is cancelled, you call a class method that decrements it. Now, any part of the application can check Booking.total_active_bookings to get the current count, and it will always be accurate because it is managed by the class itself.

You also need to validate booking reference numbers. You write a static method validate_reference(ref) that checks the format of the string (e.g., starts with 'BK-' and has 8 digits). This method does not need any booking data; it just performs a check on a string. You keep it in the Booking class because it is logically tied to the booking concept, making the code more organised and easier for other developers to find.

Finally, you add a class method from_csv_row(cls, row) that takes a single row of CSV data (a list of values) and creates a new Booking object from it. This provides a clean, alternative way to instantiate objects when reading from a file, rather than manually unpacking the data everywhere.

By using encapsulation, properties, class variables, class methods, and static methods, you have built a class that is robust, self-documenting, and resistant to common programming mistakes. Your team can now safely reuse this class without fear of corrupting the booking data. This is exactly what professional Python development looks like in real-world business applications.