This most bland sounding question is one important gate into proper software engineering. Answering it right unlocks a view that avoids bloat and enables understandable code - on a micro and macro level.
We all know what objects are, right? They are the things we create from a class with attributes and methods. They are like cars, all built the same way in the factory, but now have different drivers (owners), who put different stuff (data) in the trunk and do different tasks. And in order to create a better car, we take (inherit) the blueprint (class) and latch on some new functionality or change (overwrite) functionality (methods). The ladder is also called polymorphism, because the new car can replace its ancestor, but has a different form. The sad part of this rant - most students, professors and even working professionals would subscribe to that - although it's beside the point.
You can get objects without classes, which is called prototype based OO and very popular e.g. with Javascript. You can also go without inheritance and employ reuse by composition, where attributes are instances of the class you wanted to inherit from. And as a corollary, you certainly can do without polymorphism. So what is left? - Encapsulation and abstraction! And I would even replace the word abstraction with simplification, because that is less confusing. Even if both concepts go hand in hand - let's start with :
Encapsulation
A capsule is a shell, a package, which hides its content, protecting it from damage. In our case that means protected from user access. But every package and every function, in my language of choice even every block can have private variables. Why do we need objects? - For convenience! In fact, one could put all the functionality of a class into one closure (function with permanent private variables). And instead of calling methods from an object reference, one could call this closure with our object ID and other needed arguments. The computer wouldn't mind. The result would be the same. But the code would look convoluted. Instead of calling do_everything( pink_taxi, 'drive_to', 'munich'); it is natural for humans to read pink_taxi.drive_to('munich');. Even more importantly, the inside of the class is way better understandable if all functionality is packaged and sorted into neat little methods than if all is crammed into on function. So is it just about a bunch of functions sharing state (data)?
Simplification
YES! - even if that upsets some academics who like to carry around big words like polymorphism and abstraction. They sound like Plato, dealing with otherworldly ideas, from which everything is made. In reality, software works more like nature. One cell or organism produces another one, which produces another one. The only abstract ideas might be in the head of the programmer. In the previous paragraph I called the purpose of an object simplification. Because this is the side effect of a correct usage of encapsulation. The methods (functions), which are visible from outside the capsule, are called interface - or even shorter: API. They provide access to the functionality of the inner part of the class, but hide details. They should hide everything that burdens the user's mind and does not add meaningful degrees of freedom in his decision making. Crafting an API is an art form which includes using the right words, knowing what to leave as option and so forth (more on that here). But in the end it's all about lowering the mental strain. I prefer to focus on this most important goal by calling it simplification, not abstraction. What good are 10 most smart abstraction levels, if they just add confusion?
Making complexity manageable is the main purpose of objects. And please note that detail hiding and the encapsulation are consequences from the same enclosure.
The tools of OO are just two old ideas:
1. Variables and functions hide together in a namespace
2. Instantiation (like you do with any variable)
No wonder Bjarne Stroustrup calls objects in the classic "Annotated C++ Reference Manual" custom data types. Alan Kay, perhaps the earliest propagator of OO, said in talks that the core concepts are here encapsulation, abstraction and message passing. With the latter he just meant calling methods with arguments. Reading him also brought me to my senses regarding this matter. And to show how exactly this approach will simplify your classes and class hierarchies will be subject of another post.
Top comments (0)