Jim Perry (Machaira) |
========================================================= To OOP Or Not To OOP ========================================================= Object Oriented Programming (OOP) has been the topic of a lot of posts I’ve read lately in message boards. People asking what it means, how to do it, whether or not they should do it, flames against, posts for, I’ve seen almost everything that could be said about it. Conflicting experiences are as common as conflicting opinions based on no experience. This column will be my opinion based on experiences I’ve had, not just what I’ve heard. Still, don’t just take my opinion (good as it is J) for yourself, do your own experimenting. You’ll not only know whether or not it’s for you, you’ll learn something as well, and that’s what’s most important in the end. Human beings think in terms of objects since we’re a mainly vision oriented species. Thinking of code in terms of objects is just an extension of this. Consider a GUI system in a game – which would you rather see:
or this:
and considering you could have dozens of window objects in a games GUI this would get very ugly very rapidly. Or consider what the possible code for an RPG character would be like – dozens of variables to track everything from the character stats to his equipments, skill, spells, etc. This is an example just begging for a class. Some people might be tempted to use a UDT and functions in a regular code module. This is a possibility but consider that the functions won’t know what instance of the UDT to work with. You would have to pass it into the functions since you could have more than one character (not just a player character, but NPCs and monsters which could also all use the same code) that the code operates on. In the RPG I’m working on my entity class currently has 42 member variables 8 of which are class objects. And this is by no means the final version. Who knows how many member variables and functions it will end up with. Currently it knows how to load and save it’s data, checks to see if it’s dead when it’s damaged, checks any bonuses that it currently has that are time based to see if they’ve expired and adjusts itself automatically, knows how to perform actions and uses the necessary equipment for every action it can perform (ex. If the character starts swimming it puts away any weapon and/or shield it might be carrying), and updates it’s mana when spells are cast. There’s more to the class than these few examples but I think you get the idea. All of this code could be done in a regular code module, but imagine the headache of making sure you’re working on the correct character. People say writing OO code is more difficult than writing non-OO code. This depends on the person and their background. If a person starts their programming career learning Windows programming they’ll get exposure to some OO aspects right off the bat Almost everything in Windows is based on a Window object. A button is just a Window with some extra member variables and functions. The same for a ListBox, RadioButton, etc. They all inherit the base Window object functionality and add what they need that isn’t in the base object. I wrote code for many years before starting on Windows programming. It took a little time to switch my thinking to an OO frame of mind, but now that I have I can’t imagine writing code any other way. Humans think it terms of objects since we’re mainly vision oriented so it’s not a big deal to get used to the idea of thinking in terms of code objects. The biggest reason I hear against using OOP techniques is that it slows down a program. This just isn’t true. Any code can slow down a program if it’s poorly written. Usually the extra hoops you have to jump through to get non-OO code to work in different circumstances takes more time than cleanly written OO code. You may see examples of non-OO code vs. OO code in speed demos, but usually these demos are practically useless in real-world situations. Usually these examples are differences of milliseconds, which could be negligible anyway. Given the fact that most games are usually written by more than one person, would you rather be on a team of programmers who used OOP techniques which made understanding, using, and modifying their code easy or a team of programmers who each had their own style of programming, none of which was clean, easy to understand or modify? In the former case, usually you’ll sit down and come up with a list of objects that will be necessary and each programmer will work on a couple of these – no collision of work. In the latter case, there could be plenty of opportunities for collision of code and effort. Give me a team of OOPers any day! I’ll be the first to admit that writing OOP code takes a little more effort up front. Every single time, however, I’ve never regretted the work. It’s saved me a huge amount of time in the end. Before I started writing OOP code, even though I would have some up-front design I’ve had to rewrite chunks of code several times since it never did what I ended up needing it to do and adapting it to work with what I ended up needing it to do was a nightmare. It was more time than if I had taken the time to design it in an OOP manner. Before you dismiss OOP, take some time to learn and use it. I’ll almost guarantee you won’t regret it in the end and you’ll never go back to non-OOP if you can help it. |
Previous Columns |
Read the Freaking Manual State of the VB Gaming Community Address |
Jim Perry is: | |
A programmer at Breakaway Games |