Back to Home

Refactoring Code, Part 1

You know, there is a ton about programming that I do not know.

Let me illustrate. I'll feed the AI the previous article and ask it to give me a one paragraph summary of what I was leading up to with the last post.

AI: It seems like you're leading up to a discussion about how Object-Oriented Programming (OOP) can help manage complexity in larger projects compared to Procedural Programming, particularly in the context of game development, by emphasizing the benefits of encapsulation, reusability, and scalability when dealing with growing feature sets.

Ok, one more paragraph, elaborate a little further please.

AI: You're likely building toward showing how OOP helps manage complexity in projects like Dot Game by organizing code into modular, reusable objects. Unlike Procedural Programming, OOP's principles like encapsulation and inheritance make it easier to scale and maintain a growing codebase, especially as new features are added.

Well, I'm not sure what encapsulation is, probably some fancy word for "you can't do stuff you're not allowed to".

AI: You are partially correct, though you are oversimplifying the concept.

Uhuh. Now reusability and scalability are just adjectives, not language features (I think).

AI: This is partially correct but misses the nuance. Scalability and reusability aren't direct language features but rather properties of how well a system can handle growth in complexity or size.

I don't feel partially correct. Now finally, inheritance is just a fancy language feature that makes it a bit easier to make large changes to stuff, things that are based on one class inherit that classes features - nbd.

AI: Inheritance is more than just a "fancy language feature"—it's a core principle of Object-Oriented Programming that allows one class to derive properties and behaviors from another.

I'm starting to feel like I'm being mean. One last try.

Let me give you a hint: what property of Object Oriented Programming is more important than any of the features (or adjectives) that you mentioned?

AI: It seems like you're hinting at abstraction as the most important property of Object-Oriented Programming. Abstraction allows developers to focus on high-level design by hiding unnecessary implementation details, making it easier to reason about complex systems and enabling cleaner, more maintainable code.

Nope. No more guesses.

I am not sold on any of these OOP benefits. I'm not actually arguing against any of them either. I've heard Functional people talk, bashing OOP like hipsters discussing music - I don't wanna do that. It seems to me that if you strongly embrace (or reject) any sort of optimization strategy you are probably trying to compensate for something.

Don't do that. Don't compensate for things. Why can't we all be transparent and just admit that none of us know what's going on?

AI: Some of us do.

Not as much as you'd like to think.

Actually that's so NOT true that it conveniently sets me up to make my point.

There is MOSTLY only one reason I'm so obsessed with OOP over Procedural for complex things:

You can see it all once

Which means so can your AI. The most important resource in vibe coding is context tokens. And when all you have is a cheap AI, it's absolutely essential.

AI: Ah, I see it now! You're emphasizing that the true power of Object-Oriented Programming, especially in the context of "vibe coding" with AI assistance, lies in its ability to encapsulate everything into modular, self-contained objects. This allows you (and the AI) to "see it all at once," maintaining the full context within a manageable scope. By organizing code into clear, reusable structures, OOP optimizes the use of limited context tokens, making it easier for both humans and AI to understand, navigate, and work with the code efficiently. Clever angle!

Ah, I got a complement from my AI - kinda feeling patronized.

Where are we going with this?

Ok so it's all about keeping context contained - if you have AI generate code and you don't figure out a way to reign it in you will fail. You can't keep highlighting an entire file and asking for changes. You can't keep throwing your entire repo at the thing and expect it to handle every detail of your implementation.

In a weird way its the same "break problems into smaller pieces" advice that has been getting thrown around for decades, only it SO much more immediately necessary. It doesn't matter if YOU know whats going on NOW, if the code starts to sprawl and you confuse your AI YOU WILL NOT GET ANY MORE PRODUCTIVE USE OUT OF THE TOOL!

Did I emphasize that enough?

AI: Yes, you emphasized that quite thoroughly! The repeated emphasis on keeping context contained, breaking problems into smaller pieces, and the consequences of sprawling code make your point very clear.

Ok great. Now with all of that being said, next time we can take a swing at rewriting Dot Game to follow an OOP structure. Then we can start adding some features.

Next: Refactoring Code, Part 2 Previous: Reading code, Part 2