spagetti code[]
Near the end of my degree program I got an internship where they handed me a 1.5 million line pile of C++ mess they'd bought and asked me to port it from MFC to an embedded Linux platform. Naturally, my first step was to try and make sense of it. I downloaded Doxygen and had it print out some class diagrams for me. I expected it to look something like the pretty UML charts from all of the toy examples they used in school. Instead it was just a giant wall of spaghetti with every class connected to every other class in no coherent order. At the time I thought the code was just poorly thought out. After graduating and seeing more real world examples I've come to realize that all object-oriented code ends up looking like this. Encapsulation simply isn't possible. Even in my own code I've spent weeks in analysis paralysis, exactly as you've described in this video, trying to figure out how to refactor my code to adhere to all of the exalted OO design principles and reach that "loose coupling" holy grail.
You DO end up with these really ugly trees of classes under "manager" and "controller" control objects and control objects and their sub-objects, even though all of the programming bibles out there proclaim it a sin. Without garbage collection you practically HAVE to do it this way anyway in order for destructor chains to make any sense at all. The cleanest "OO" code that I've seen (and written) ends up taking all of the functionality out of the classes and simply using them as storage constructs to be passed as arguments to static/stateless methods. The cruelest joke though in the four years since
I've graduated is that I only seem to be able to get Java jobs where people are still in love with AbstractProxyFactoryBeanManagerServiceDeluxeWithCheese style programming. I end up having to just keep my heretic beliefs to myself and write the same boilerplate code as everybody else. Since Java 8 I even have to make all of my methods return the same Optional<Whatever> objects since these people have forgotten how computer memory works and need such nightlights to ward off all of the big scary null pointer exceptions.
- "The cleanest "OO" code that I've seen (and written) ends up taking all of the functionality out of the classes and simply using them as storage constructs to be passed as arguments to static/stateless methods. The cruelest joke though in the four years since"
Meaning you have a struct without procedures.
3[]
I've noticed that a lot of people are just responding to this video with some generic comment about how OOP is easier to read and write, and that's the advantage. Even a child could understand/write OO code! I don't agree.
How do I get to say this? Well, I'm something of an academic novice to programming. I've done a bit of it in different languages (from Scheme to Ruby), but I've never put together a big project in any language—so I don't get to call myself an expert. This, however, gives me the distinct advantage of being able to think from a novice's perspective.
When I sit down to write something in an object-oriented way—lets say in Ruby—I get nervous. I feel like I'm building a structure without knowing exactly what I'll need the structure to do. I try to rely on my instincts, but I start having to think in a very abstract (even metaphysical or ontological) way pretty quickly. "Okay, so I'm writing a game. I know what games are like: they have players, enemies, walls, sprites, etc. Wait, so should I write a class called 'character,' and the players and enemies are the subclasses that inherit from it? What if I want multiplayer and I want to keep networking states separate from enemy states? And what about the game world? The overlay UI? The map loader? Are these classes? What constitutes an instance of these classes? . I don't know what I'm doing." This is my experience of the problem at 25:45.
When I look at different peoples' code or APIs, they do this metaphysical/ontological work in different ways. I end up trying to get into their heads as I read the code. "Okay... that way of doing it works, is readable, and matches the intuitions most of us have, but they overloaded the operators in this weird way to get it to work. Now I don't know what operators will do what and when…"
It's not enough to say, "Well, these are just bad programmers! Write good programs!" After all, one should not need to have a concretized ontology in mind just to write a program. Philosophers have trouble doing that, so programmers will definitely have a problem with it.