OOP and cars
When I first learned Object Oriented Programming (OOP) a few years ago the book I was reading had a strange obsession with cars.
Imagine you have a car, it said. A car is composed of a body, four tires, and an engine. Furthermore, you can have a Ferrari, which is a specific type of car, or you could build cars with different types of wheels. This is the way it explained the concepts of Polymorfism, Inheritance, Composition, and Instantiation. With cars.
I came from a background in C, a procedural programming language, where everything is structured around procedures and procedure calls. And I was utterly confused.
Was the concept of OOP what was confusing to me? It was different, for sure, but I don’t think that’s the main reason. The main reason was that it was so focused on CARS. This was a book that presupposed some programming background; cars is how I would explain OOP to my parents, who have no programming experience, but I think in this case it was detrimental to my understanding. Give me a real world example (dumbed down, if you want); explain to me how you would implement a GUI using OOP so I can see how it differs of the procedural paradigm.
This approach seems to be very common. Just look for “object oriented programming car” on your favorite search engine, and you will be presented with a multitude of diagrams showing all the attributes you could assign to a car. Or try to understand the Builder pattern and you will be presented with a, literal, house builder.
One book that approached this issue in a way I liked is the famous Design Patterns. The second chapter is a whole case study on how to apply design patterns to a specific problem, a WYSIWYG document editor. To me, this makes understanding how and when to use these design patterns easier and more clear. I can understand why you would want to take that approach, how you would do it, and some of the consequences of using that pattern.
Can we forget about cars?