Why Does Tesla Hide Things?

A no-code version , from a Tesla fan, to address the dilemma of abstraction vs. encapsulation in an object oriented software design.

Why is object-oriented programming so preferred? Besides being widely accepted and highly demanded for decades, its preferred because it just makes sense to a human brain! It makes sense because it is closer to real life.

Abstraction and Encapsulation are the main tools at the disposal of anyone using OOP to their advantage. Being very similar, both of them are so close in concept yet so apart in intent that confusion is prevalent. The problem only arises when we know how to use them but do not know when & why to use them. The how is answered with the code, we will use the example of Tesla to see when and why, abstraction and encapsulation make things outclass.

Abstraction in Action

What you just saw is the interior of a Tesla Model X, the quickest SUV on earth, which goes from 0–100kmh in 2.8s (mind-blown already), never requires a fuel, over-the-air updates and feature addition, bioweapon defense mode that uses a powerful filtration system to render hospital grade interior air quality, 5000 pounds towing capacity, autopilot navigation , auto lane changes and ramp maneuvers.

The best part; your only point of access to all these out of the world features is the 17-inch touchscreen display at the dash. You do not get to know how any of this works, neither do you need to. Tesla doesn’t come with the conventional clunkier panels and annoying knobs rather the minimalistic approach is what makes it unique.

This essentially what abstraction is; Display of only the essential information and hiding the rest of it where the sole purpose of selective display is to make the user experience simple and effective. Simple, because they can see only what they need and effective because the display is totally independent of whatever is happening at the background. If one of those nerdy Tesla guys changes something in the software overnight, the Tesla owner still gets to use the same interface in the morning. This is what we call decoupling in the software terms and this is a sweet fruit of abstraction.

Encapsulation in Action

Tesla comes with upgradeable software-locked features. The most prominent of them is the battery capacity upgrade and autopilot feature enabling. What this means is, Tesla sells the base version of the , let’s say, Model S with a 75 kWh battery pack, but software-locked at a 60 kWh capacity. It allows the company to lower the entry price of the Model S, but it also results in Tesla shipping 15 kWh of unpaid battery capacity. In order to unlock the extra battery capacity , via an over-the-air update, you need to pay an extra amount. Similar to this, the autopilot feature is available for a free trial of 30-days after which it gets locked and can only be unlocked when you pay to subscribe for it.

If we look under the hood, the abstraction is still there. There is information or functionality that is hidden but only this time the intent is different. This time the focus is not on simplifying the user interface rather there is an authentication and validation that is being performed first and based on that you can get selective access. Moreover, the access is circumstantial and can vary for every user.

This is what encapsulation is; one of the many possible implementations of abstraction. Whenever we see encapsulation anywhere, the abstraction is by default. The difference is, our focus has moved from the user to the system. The intent is now data integrity and controlled access. In a way, you are interacting with the hidden domain but there are constraints to it and those constraints are maintained only by encapsulation.

Why are they same & Why are they different

Enough with the Tesla praise, let’s see how all of this applies to an object oriented software design. Listed below are the few points that I think can make us understand when & why should we opt for abstraction and encapsulation.

— Concern —

In abstraction, our concern is the User. We hide the details because the intent is to simplify the experience for a user.

In encapsulation, the concern is the system. You can get selective/controlled access to data but the encapsulation in place can help in authentication and validation.

— Motive —

Abstraction follows a ‘need not’ motive. I am hiding information because the user need not to see it. Just providing what he needs, nothing more nothing less.

Encapsulation follows a ‘should not’ motive. I am hiding information because you should not see it as it is vital for my data integrity/privacy and also helps me in performing validations before I grant you the selective access.

— Decision Boundaries —

Abstraction is a design decision. If I would choose not to use it, my product design is what gets affected the most.

Encapsulation is an implementation decision. Not using encapsulation can result in compromise on your data integrity and can cause logical and functional errors.

— Triggers —

In order to see an abstraction in action, we have to see how someone uses or interacts with your product.

Encapsulation can be seen when an event takes place for example accessing features or data that requires controlled access.

— Extent —

In abstraction, since the intent of hiding was to hide away the complexity, the point of access provided serves the purpose of making a use of underlying hidden functionality.

In encapsulation, the intent is to grant selective and varying access and to maintain the security and validity of data hence the access points provided do more than just providing an access. You can send data to and fro, and can make use of the underlying functionality while the system does what it needs to do to maintain the checks.

To conclude, abstraction and encapsulation are very different but highly-related concepts. I would regard encapsulation as a subset of abstraction. It is only the intent that varies. It is only when we make the apt use of them, that we can truly benefit from the power of object oriented programming paradigm.