To OOP or not to OOP, that is the question
Author
I''m new to programming in C++ and opengl. I see in NeHe''s tuts he doesn''t use OOP. I do understand OOP code its just that I''m not how shall I say, fluent in it. So I open up the newest Zelda code and it has been converted to OOP.
Well my question is, what is the point to use OOP? I mean if one can code all those tuts without using OOP, then one can also code an entire game without OOP correct? Maybe its just me, because its new to me and I''m used to reading non-OOP code that reading and following OOP code is more difficult, and writing OOP just seems like more unnecessary and complex work compared to writing non-OOP code. Is this just because I''m new to it or does everyone share my views on this?
Thanks for responding.
OOP is very useful when writing large programs. It allows the programmer to break the game into smaller pieces of code that are easier to write and debug. It also allows the programmer to change parts of code without needing to recompile the entire project.
The most useful feature (and why most people use it) is it allows for code reuse. If you use OOP you can write a code segment, like a engine, and use it in many different programs. This allows you to write programs much faster and easier than if you wrote a special engine for every game you make.
"cogito, ergo sum" -Descartes
The most useful feature (and why most people use it) is it allows for code reuse. If you use OOP you can write a code segment, like a engine, and use it in many different programs. This allows you to write programs much faster and easier than if you wrote a special engine for every game you make.
"cogito, ergo sum" -Descartes
Along the lines of what what he was saying, if you think about it, everything breaks down into objects.
For example, you have a human object. Then you have arms, legs and feet, and then fingers and toes. Each part controls the other part, and thus, OOP is created.
I find it very easy to implement OOP rather than just functions and variables. It does make maintaining large projects extremely easy.
Just wanted to add that.
-Vic
Go away or I will replace you with a regular expression.
For example, you have a human object. Then you have arms, legs and feet, and then fingers and toes. Each part controls the other part, and thus, OOP is created.
I find it very easy to implement OOP rather than just functions and variables. It does make maintaining large projects extremely easy.
Just wanted to add that.
-Vic
Go away or I will replace you with a regular expression.
It''s a small hill to climb over when your making the transition from procedural to OO programming, but when your on the other side, your glad you made the trip. Just as an example, when writing a game similar to the classic (ect)Mario(ect) sidescrollers:
PROCEDURAL:
Mario''s position is defined in a struct/ globals/ whatever, likewise with all his enemies. All of the functions that deal with that data (jumping, collision detection, firing fireballs, ect) are called somewhere else in the code. In effect, poor mario is spread out all over the place. As far as adding/removing anything goes- you''ll have to hunt for the right location, given that you have functions called from functions called... all the way back to WinMain(); Finally, the function names: Jump(Mario, JUMP_SUPER);
OBJECT-ORIENTATED:
You define a class "character" in character.cpp/.h that has attributes such as screen position, size, health, or whathaveyou... and any functions that deal with that data (move to the left, CheckFalling, ThrowFireball). Everything is in a nice, neat, sorted package. It gets much easier to read, as well- Mario.Jump(JUMP_SUPER);
Anyways... do what you like... but oop definately gets my vote as the way to go.
-Tok.
PROCEDURAL:
Mario''s position is defined in a struct/ globals/ whatever, likewise with all his enemies. All of the functions that deal with that data (jumping, collision detection, firing fireballs, ect) are called somewhere else in the code. In effect, poor mario is spread out all over the place. As far as adding/removing anything goes- you''ll have to hunt for the right location, given that you have functions called from functions called... all the way back to WinMain(); Finally, the function names: Jump(Mario, JUMP_SUPER);
OBJECT-ORIENTATED:
You define a class "character" in character.cpp/.h that has attributes such as screen position, size, health, or whathaveyou... and any functions that deal with that data (move to the left, CheckFalling, ThrowFireball). Everything is in a nice, neat, sorted package. It gets much easier to read, as well- Mario.Jump(JUMP_SUPER);
Anyways... do what you like... but oop definately gets my vote as the way to go.
-Tok.
Author
Ah I see. Very nice explanations, thanks very much. Only thing I don''t yet get is in what way 1 class is derived from another. Or even if that need be done in all situations or just in some. But I still have a lot of reading to do on the subject so I''m sure I''ll get there eventually.
Just some. To continue with the Mario/character example:
You have a class named Character that contains screen position, size, health...basically anything that all characters would have.
Then you have a class named Mario which has the jump ability, the ability to toss things (since the screen is of SMB2), and so forth. This class is derived from Character since Mario also needs to keep track of screen position, size, health, etc.
You have another class, Monster (since I don''t remember that boss''s name) that is derived from Character and has the functions for spitting eggs.
You also have a generic Character for each of the little monsters that appear on the level that don''t do anything special.
And thus, you have an OOP design (OOD) of both derived classes and non-derived classes.
Hope that made sense : )
You have a class named Character that contains screen position, size, health...basically anything that all characters would have.
Then you have a class named Mario which has the jump ability, the ability to toss things (since the screen is of SMB2), and so forth. This class is derived from Character since Mario also needs to keep track of screen position, size, health, etc.
You have another class, Monster (since I don''t remember that boss''s name) that is derived from Character and has the functions for spitting eggs.
You also have a generic Character for each of the little monsters that appear on the level that don''t do anything special.
And thus, you have an OOP design (OOD) of both derived classes and non-derived classes.
Hope that made sense : )
also OOP (assuming you mean C++), is easier to make the code look pretty and organised, ah perfectionism
I love OOP. When I think of making a program, I think in terms of what classes I''ll need to create. That way, if I give up building a program, I''ll have already created classes that I can use elsewhere, even if the program never gets finished. One example I can think of is I designed and coded a whole thing that implements LAN connectivity (both TCP and UDP) with classes for client and server and auto-server-finding capabilities, but to date I haven''t used the code. (Anyone interested?)
Anyway, OOP is good.
Anyway, OOP is good.
Required reading for anyone interested in OOP: Design Patterns - Elements of reusable object-oriented software by Gamma, Vlissides et al.
"I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours." - - Stephen Roberts
"I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours." - - Stephen Roberts
quote:Original post by Silvanis
You have another class, Monster (since I don''t remember that boss''s name)...
Trivia: Bowser.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
