If I’m programming in a monolith, I change the Color property to a List and I get a big red dot with the number of errors the change caused in the bottom of my IDE and it tells me all of the places I need to change the code.

If my car class is part of a Nuget package. I change the version number to represent a breaking a change following the standard semver semantics. When the consumer upgrades to the latest package, they either get warnings about Color being obsolete and use Colors instead or I just completely remove the Color property and they get a red dot and change their code or decide they don’t have time and keep the old package around for awhile.

If I’m writing an API, and since I did properly separate my domain model from my view model, I both map the first item in the Colors list to the Color property in my view model and I create another Colors property.

These are solved problems.

Maybe we're exposed to different evidence but it seems like academia heavily favors non-OOP such as functional programming. Programmers also make repeated citations to SICP class they enjoyed in college but were forced to deal with OOP when they got a real job. It's the commercial industry that pushed OOP. Universities seem very anti-OOP while commercial businesses like Adobe/Microsoft/Google use OOP languages like C++. Other companies that write back office "enterprisey" software also favor OOP languages like Java/C# over non-OOP such as Haskell. I also remember the 1990s when professional programming magazines had monthly articles evangelizing the new thing called "object oriented programming" and you had full-page ads for Turbo C++ and Microsoft C++ that touted its new OOP features.

>My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket.

I don't understand why your example as you've constructed it proves what you want it to prove. If we use your "car color" as a text template to test the validity of other computer science ideas:

Database table paradigm:

  create table car (
    vehicle_id varchar(20), 
    color_code varchar(1)
  );

Algebraic data types such as product type:

  struct {
    char vehicle_id[20]; 
    char color_code[1];
  };

It seems like your example applies to any and all computer science concepts that attempt to model real-world data so maybe I'm missing something?

You can define an object to have more than one color, or maybe instead of having a color have a color pattern. How creative is your imagination? If you use a tuple of (r, g, b) to represent color in a functional language, you will still have the same problem when you realize you can have multiple colors or design patterns. if your mental model has a mismatch with the real world, you will have problem at some point.

Your example also doesn't specify a business context. What kind of software am I building such that I need to model a car and it's color? That simple question will entirely change how the OOP model is designed.

OOP is easy to teach because it's easy to use, to understand. But again, if you use simple poorly thought out OOP, it may work- just badly. And of course there's the problem of "those who can't do, teach" and often those teaching programming are poor programmers.

A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color scheme ID would be all you need.

Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors.

In spite of appearances, it's not a completely trivial problem.

Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is.

And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them.

Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options.

OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.

Absolutely not! I doubt that anybody was ever taught OOP in an academic PL course, unless it was really an "introduction to programming" course, or their professor was working on this topic at the moment. The meaning of a program in an object oriented language with imperative features and inheritance is not pretty.

There are aspects of object oriented programming that are useful for structuring programs (hidden state) and others which are a recipe for disaster (recursive types). This complexity is always swept under the carpet when teaching OOP. Classes/inheritance/objects are always taught via imperfect analogies, which should tell you everything you need to know about how "easy" OOP really is.

No, the reason it is taught so widely is purely practical. It's a popular paradigm and a lot of practical programming projects might need an OOP background.

---

Edit: Just to be clear, I'm not trying to say that OOP is bad per se.

The information hiding and namespacing aspects of objects are really useful, both in theory and in practice. It's just that I think that implementation inheritance is an imperfect way of facilitating code reuse and not something you should teach to new students...

And most professionals agree with you. “Prefer aggregation over inheritance.”

Which by the way Resharper makes really easy. You add a private variable to your class of the type you want to aggregate and it creates wrapper methods in your aggregating class that just calls your other class.

You can do LISP in vi or emacs just fine, but for java some kind of IDE to handle the sheer data processing load of source editing is necessary.