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 ad 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 doing 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 descendant, 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 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 in one closure (function with permanent private variables). And instead of calling methods on 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 packaged and sorted out in 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 sounds like Plato, dealing with otherworldly ideas, everything is made from. 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. I called it in the previous paragraph simplification because this is what an object does. It is providing a drastically simplified interface to the functionality hiding inside. Thus making complexity manageable, by hiding the details I don't have to know about right now. And please note that this hiding and the encapsulation are consequences from the same enclosure. So OO is really just a combination of two old ideas:
- Variables and functions hide together in a namespace
- 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, the maybe earliest propagator of OO, said in talks that the core concepts are here encapsulation, abstraction and message passing. With the ladder he just meant calling methods with arguments. Reading about him also brought me to my senses regarding this matter. And to show how exactly this approach will simplify you classes and class hierarchies will be subject of another post.
Top comments (0)