1. 3
  1.  

  2. 3

    This rant has no code. No examples at all. Just hand waving. The main point seems to be that people name things, then use inheritance a lot (eek!), then refuse to write new objects when new stuff comes up. I admit it is likely that many working programmers make these kind of mistakes, I’m not sure what it really has to do with OOP in general or C++ in particular.

    1. 1

      Yup, you only need a vtable if you have virtual methods…

    2. 3

      Sigh.

      https://www.artima.com/articles/the-c-style-sweet-spot#part3

      Bjarne Stroustrup: My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.

      Bill Venners: What do you mean by invariant?

      Bjarne Stroustrup: What is it that makes the object a valid object? An invariant allows you to say when the object’s representation is good and when it isn’t. Take a vector as a very simple example. A vector knows that it has n elements. It has a pointer to n elements. The invariant is exactly that: the pointer points to something, and that something can hold n elements. If it holds n+1 or n-1 elements, that’s a bug. If that pointer is zero, it’s a bug, because it doesn’t point to anything. That means it’s a violation of an invariant. So you have to be able to state which objects make sense. Which are good and which are bad. And you can write the interfaces so that they maintain that invariant. That’s one way of keeping track that your member functions are reasonable. It’s also a way of keeping track of which operations need to be member functions. Operations that don’t need to mess with the representation are better done outside the class. So that you get a clean, small interface that you can understand and maintain.

      1. 2

        I was struck by how well these two short paragraphs described some of my own struggles.

        By writing the solution following OOP design principles, we abstracted the problem away and, as soon as it changed, the solution fell apart like a house of cards.

        This is where I would expect people to wonder what went wrong, try a different path and update problem solving strategies based on the postmortem results. However, every time I’ve seen this “it’s time to rewrite” scenario, the same strategy is used: OOP design principles, coding a snapshot of the new mental image of the new current problem space. And so the cycle repeats itself.

        1. 1

          100% agreed with what’s written there, though the article is from 2019, and there isn’t really much there that wouldn’t be already said in other articles.