Wasn't sure whether to post this in Game Design section, but it seems that that one leans towards actual gameplay design, whereas this topic is more about programming decisions. In any case mods can move it.
Just want to say that this is the first in a series of questions I planned out oriented towards using proper OOP.
A while back I came across a post on here that made me rethink my ways in writing OO code. I cannot quote the individual but he said something along the lines of "it's not OO programming if you're just throwing related functions and data in a class and calling it a day". It kind of struck a chord with me and I got to thinking how most of the code I had was just that, things were Objects for no reason. For example in my initial iterations of frameworks, I had an Application class, a WindowsInterface class, a Utility "class" that just had all static functions (because it was convenient to just write Utility::TransformVector or something like that). Everything was a class just because.
About a year ago I decided to step back from that and write code without any classes at all just to see the difference. I rewrote my entire framework in that style and really never looked back since. I no longer have to worry about class instances, about what seem like useless restrictions like having to pass hidden "this" pointers in window parameters or managing objects that didn't even seem like objects to being with.
So on to my question. I'm now reading Code Complete 2 (after having read 1 years back) and with everything I've learned I'm tempted to give OOP another go. With a renewed mindset and a renewed appreciation for constraint. However that also got me thinking of whether or not all things conform well to OOP, maybe things like general low level frameworks or systems programming are inherently anti-oop? Maybe I'm just trying to push for something that's not really needed at this point? The reason I came to that conclusion is because I'm re-reading some design chapters right now in CC2 and he speaks of designing software at high level first thinking of it like a house. Designating subsystems, then designating modules in the subsystems, then designing classes and planning their interactions and only then moving on to functional execution of class methods.
As I sat down to rewrite my code, I realized that it's really difficult to even begin. I can't specify subsystem interaction for example and as per the book I have to restrict subsystem interaction because "it's chaos if every subsystem can access every other subsystem". Well that's the way I have right now, I have a SoftwareRenderer, UserInterface, Resources, Windows, Application and GameEngine subsystems. I see no reason to restrict SoftwareRendrer to any one, and as of right now since I'm coding in C, all a subsystem has to do is include "SoftwareRasterizer.h" and it's good to go with making calls. It's flexible and convenient.
So besides subsystem interaction, I'm also having difficulty breaking things down into meaningfully classes. I blame it on the fact that a framework is by definition a low level system, so the obejcts can't be really straighforward common sense abstractions, they must be EventListeners and FrameDescriptors, which are abstractions non-the-less but at a much less intuitive level.
Despite being confident that I don't really need OOP to get the job done, it's nagging me that it's so difficult for me to find an OO solution to a framework. Does that mean that I don't understand what a framework requires if I can't easily delineate the objects required to create it? Should I still push to get there? Or are some things just not as suited for OOP as others?
Thanks.
↧