Classes: Possible to overdo it?
Author
Hi there, I'm a game development n00b. I'm not so new to programming: I enjoy C, C++, and x86 Assembly. I've written tons of hobby projects, and I'm soon going to uni to become a computer hardware engineer.
Well, where do I start...?
My question is when does wrapping everything in classes become a hindrance? I've seen a lot of code where game developers wrap everything--and I mean EVERYTHING--in an object. They use singletons instead of a separate CPP or C files with global functions and state variables. Even for things that seem procedural in nature, they somehow manage to wrap them in some object system.
My question is also if it's generally frowned upon to use a less complex architecture when writing game code? Like, say, if I showed some of my portfolio to a developer; suppose it's a fully working game; would they not hire me until I take the neater, more painful path?
Because, I dunno, for some segments of code it seems less useful and intuitive to wrap them in objects. It seems a lot of time could be saved if I wrote some parts of the game in traditional code. It sometimes feels like using a chainsaw to cut a tomato because everyone else does.
Well, thanks.
Many people make the mistake of believing that putting everything and anything into a class makes them good, OOP-driven programmers. Rather - you must use the paradigm that is most suited for what you need to do.
Yes, excessive OOP is a common error. It is often caused by the infatutation many programmers have with "buzzword oriented programming".
OOP clearly has it's uses, but pesonally I try to follow the following rules of thumb:
If I cannot identify a proper invariant for a type, then there's rarely any need for making it an abstract datatype.
I would generally rather make something data-driven than build a class-hierachy.
The proper abstraction for a side-effect free operation is the function not the method. Or put in another way: A types methods should be the minimum set of state changing operations, not all procedures somehow relating to a type.
OOP clearly has it's uses, but pesonally I try to follow the following rules of thumb:
If I cannot identify a proper invariant for a type, then there's rarely any need for making it an abstract datatype.
I would generally rather make something data-driven than build a class-hierachy.
The proper abstraction for a side-effect free operation is the function not the method. Or put in another way: A types methods should be the minimum set of state changing operations, not all procedures somehow relating to a type.
The difficulty with OOP is not in the use of objects, but in designing a proper system, and classes are one of the tools to assist you in that.
In my opinion, OOP really starts to shine in large projects with multiple developers working on it, but it doesn't hurt to show your understanding of OOP in relatively small demos. But don't just "wrap" your procedural code in classes: demonstrate common sense and apply patterns where appropriate. Good code is simple and flexible.
In my opinion, OOP really starts to shine in large projects with multiple developers working on it, but it doesn't hurt to show your understanding of OOP in relatively small demos. But don't just "wrap" your procedural code in classes: demonstrate common sense and apply patterns where appropriate. Good code is simple and flexible.
Object usage is not object-oriented programming. In particular, there are only a handful of cases where singletons are a valid object-oriented construct, as opposed to an object-based procedural construct or an useless an deluded effort.
In practice, object-oriented programming is about making code easier to reuse at the cost of making it harder to develop. If you can't expect to reuse it with at least a minimal probability, making it an object will only waste time.
In practice, object-oriented programming is about making code easier to reuse at the cost of making it harder to develop. If you can't expect to reuse it with at least a minimal probability, making it an object will only waste time.
Quote:Original post by ToohrVyk
In practice, object-oriented programming is about making code easier to reuse at the cost of making it harder to develop.
I find that to be closer to the theory, while in practice it's really just a set of tools for (a) code organization and (b) modelling. :S
I believe your overall question is:
"When is it appropriate to sacrifice generally accepted good programming practices?"
That's basically the answer: Namely, when in your judgement, your project is better served by ignoring them.
"When is it appropriate to sacrifice generally accepted good programming practices?"
Quote:
Because, I dunno, for some segments of code it seems less useful and intuitive to wrap them in objects. It seems a lot of time could be saved if I wrote some parts of the game in traditional code. It sometimes feels like using a chainsaw to cut a tomato because everyone else does.
That's basically the answer: Namely, when in your judgement, your project is better served by ignoring them.
Quote:Original post by CreativeCombustion
My question is when does wrapping everything in classes become a hindrance?
When it becomes a hindrance; when it's more time and effort to do so (including time spent debugging/maintaining) than not.
Quote:
I've seen a lot of code where game developers wrap everything--and I mean EVERYTHING--in an object. They use singletons instead of a separate CPP or C files with global functions and state variables. Even for things that seem procedural in nature, they somehow manage to wrap them in some object system.
Singletons are a waste, but eschewing globals for globals wrapped in a class is occasionally a problem. Personally, I find that globals in a class aids in debugging access to the global. Free functions are less of a concern. The key here though is 'seem procedural in nature'. What seems procedural to you probably doesn't to someone approaching it in an OOP manner (and almost certainly doesn't to someone approaching it in a functional manner).
Quote:
My question is also if it's generally frowned upon to use a less complex architecture when writing game code? Like, say, if I showed some of my portfolio to a developer; suppose it's a fully working game; would they not hire me until I take the neater, more painful path?
It's frowned upon to hinder maintainability and extensibility. If it works though, you'll be given a good amount of credit for that. It depends on the developer and what priority they give to 'make it work' vs 'we have to maintain this thing'. In general, the game industry is a lot more lenient towards the former.
Yes, it is totally possible to overdo it with classes. Sometimes it's just the language. For example, if you want to implement callback functions in Java(something very simple and quite fundamental), you have to wrap your function to an object(functor). In other languages, such as Python or Ruby, you don't have to wrap everything into classes, because all concepts(functions,modules,"primitives", even classes themselves) are already objects. Other times, it's the programmer, who thinks that, in order to write proper "OO" code, he must put everything inside a class, even when it's not necessary. If a function is related to a class but can be non-member(it doesn't need acess to the internals of the class and it's not virtual), then it should be. It actually increases encapsulation, because you have one less block of code that depends of the implementation of the class.
You should not mix OO and procedural methods of programming. They are completely different ways of thinking. There are few rules on what you should be a separate class, and what should be merged.
I'll see if i can find them.
A lot of object orientated languages do tend to have a lot of classes. If your finding your just writing the same procedural code, and putting it in a class. You have probably designed it badly in a oo way.
I'll see if i can find them.
A lot of object orientated languages do tend to have a lot of classes. If your finding your just writing the same procedural code, and putting it in a class. You have probably designed it badly in a oo way.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement