Public and Private Interfaces In OOP

Welcome to another section of OOP with Python. If you read the last post, I talked about OOP and other object-oriented paradigms like OOA and OOD. This time, we'll look at encapsulation and abstraction, and their role in creating public and private interfaces. To further support this, I will be using UML to show them in detail (I will cover UMLs in the not-too-distant future but if you are impatient, you can pick up UML Distilled and read).

Interface

The fundamental purpose of modeling an object is to determine what the public Interface of the object will be. An interface is the collection of attributes/instance variables and methods that other objects can interact with, and have access to. Let's use the television as an example. The TV is an object, and the interface to the TV is the remote control. Each button on the remote represents a method that can be called on the television. When the access these methods, we are not from where the TV gets its signal, the signals are sent from the remote to the TV and other functionalities that make the TV work (speakers). The TV internals hides these things - the workings/implementations that make the TV work - from us.

Encapsulation

The process of hiding these implementations of an object is referred to as encapsulation. But, encapsulation's meaning is completely different. In other terms, it means to hide something, but in programming, it means to create a wrapper on the attributes. The public interface, on the other hand, is essential. It needs to be properly designed as other classes depend on it, meaning a change in the interface will affect those classes using the interface. Other parts can be changed and it will not affect the public interface, but if the interface is altered, it will break an application. To prevent this mistake from happening, one might spot a python variable starting with _. It means that it is not a part of the public interface.

Abstraction

Abstraction is another object-oriented term related to encapsulation and information hiding. Abstraction is the process of encapsulating information with a separate public interface. Any private element can be subject to information hiding. Take a car as an example. A car driver (client) needs to interact with the steering, accelerator, and brakes. The workings of the brakes, engines and the entire work do not matter to the driver, but to a mechanic (programmer), it does. Here are two levels of abstraction for a car from the driver (client) and mechanic (programmer) perspectives.
Note: a leading _ can be used to suggest that it is not a public interface.

Key Takeaways

Overall, the takeaway from this post is that one has to make each model understandable to others and also ourselves in the future whenever we need to revisit and change how things work and interact with other objects.

1. No use of obnoxious names, like if an attribute should be named instance_id and user_id for easy identification, one goes and use id for everything (because it's an object and it's encapsulated in an object/class won't cut it.)
2. To make things somewhat easy, you should make sure your objects are nouns, methods verbs, and attributes as nouns or better yet, adjectives. It might be hard to do if you suddenly become conscious of it, but it'll naturally stick with you - like muscle memory - if you practice.
3. When you design an interface, imagine what you want to be publicly accessible, and what is not. Even for private matters, you decide who you in your circle should know or have access to them privy information. In other words, treat it like it's a real-life scenario. You'd want everyone to know you got a new car but will not let a car painter service its engine. Ah well, till next time. The different relationships in OOP will be covered. In the meantime, keep practicing!