Sign in to follow this  

Namespace versus Class

This topic is 3743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im slapping up a small game before i leave for uni, decided to make a small little engine for it similar to the one at http://gpwiki.org/index.php/SDL:Tutorials:Simple_Engine_Framework. Iv been doing c++ for about 4 months now Their engine is based in a class, and has basically the same functions as mine has/has planned but they chose a class over a namespace. The only reason im making an engine is to shorten the effort on my part everytime i wish to draw an image, blit the screen etc. i come from a non OOP background, so it makes more sense to me to just have a load of functions in include files rather than tying them to a class. Im probably doing it wrong this way, because in every C++ bit of literature i read its classmania Could an old hand here explain some of the maybe not too obvious benefits for either way (an engine as a Namespace or Class) Cheers

Share this post


Link to post
Share on other sites
I'm not an expert or old school :) But I can say that both namespaces and classes can be used together perfectly.

You can combine your data and functions(methods) which work on that data to logical objects(classes).This makes it much easier to manage when things start growing.

Namespaces are just a way to make blocks of your code and give it a name.This helps you organize your code and prevents name clashes.For example you may have a variable/class/struct etc. in your engine named "uber" now if someone using your engine uses the same name the compiler will complain with redefinitions.
If you put your code inside namespace(s) like uberEngine then you will prevent this.
Using your code inside the namespace is just done by adding its name infront of it like :
uberEngine::someStruct ohMy;
You don't need to add that to the beginning if you are already inside the scope of that namespace.
So basically I can have namespaces like SoundSystem and have lots of classes dealing with Sound inside that namespace.
Hope that helps and correct me if I said anything stupid [smile]

Share this post


Link to post
Share on other sites
The actual comparison you want to make is between procedural programming (which is what you meant by placing free functions in include files, I assume) and object-oriented programming. First, a simple statement of fact: neither is globally "better" than the other.

Procedural designs are more difficult to refactor because of the increased coupling between modules (which interact with each other directly, instead of using parametric interfaces as in Object-Oriented programming). This can lead to difficulties in places of your game that you cannot plan ahead perfectly (because you will have to either drop a nice feature or work hard to adapt your code to it). By contrast, good object-oriented design strives to improve the modularity of code beyond the typical procedural modularity, and so makes code easier to refactor.

Another side-effect of procedural code is that unit testing becomes more difficult, because unit testing relies a lot on parametrizing the objects being tested with mock parameters, something which is not possible because procedural modules are implicit (and thus, non-reseatable) parameters of your objects.

Procedural designs have the advantage of being easier to use and develop if their assumptions are correct, because they crystallize and hide those assumptions better than an object-oriented design (which by definition strives to make assumptions as explicit and parametrable as possible). Code which uses a procedural module (with a nice interface) tends to be simpler and shorter when compared to object-oriented code.

In short, procedural programming improves programming speed by making strong assumptions about the application. This has the side-effect of making refactoring and reuse more difficult (because these are harder when assumptions are made). So, if you know you won't change or reuse your design, use procedural programming, but be prepared to face hell if you actually need to change or reuse it down the road.

Share this post


Link to post
Share on other sites
I don't even think that making a God class named "Engine" is the OO-way. A class must have a single responsibility, Engine most definately doesn't. It is in fact a way to break the design: When you have a lot of functions that need to "communicate" through globals, you wrap them all up in a class, make the globals into private members, and you suddenly think you're doing it the OO-way, when in fact you don't. It is in fact better OO design to have a bunch of indepedent,reusable free functions instead of unrelated methods inside a God class. The best of all, of course, is to have a bunch or reusable single-responsibility classes.

My advise? When it makes sense to have a namespace, have a namespace. When it makes sense to have free functions, use free functions. When it makes sense to use a class, use a class. In your case, you can have a namespace Engine, which contains a variety of indepedent free functions and smaller classes. All this together makes your engine. You don't need to have an explicit Engine class.

Share this post


Link to post
Share on other sites
Quote:
Original post by HumanoidTyphoon
I would suggest that you get into OO and make your own life easier, and your code stronger and more versatile. Its easy to get into because it makes sense.


OO doesn't make your life easier, code stronger or more versatile until you completely and fully understand how to properly use the OO language of choice and the tools that go with it. Until then you have just as much chance, I believe, of writing poor code.

Also, it's not easy for everyone to get into. Just cause it came easy to you doesn't mean it's the same for everyone else :) My friend has been trying off and on for about 2 years now. He's just procedurally inclined ;-)

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Procedural designs are more difficult to refactor because of the increased coupling between modules (which interact with each other directly, instead of using parametric interfaces as in Object-Oriented programming).

There's nothing inherently tightly coupled about procedural design. The difference between procedural and object oriented programming as expressed in most popular languages today is that OO binds the operations (procedures) to the data types (classes) they operate on, with the inheritance mechanism potentially enabling polymorphic dispatch. A procedural design can be highly reusable simply by defining "interface types," such that a complex routine does not operate directly on a user type (the equivalent of a class) but instead on a simple aggregation defined in tandem with the procedure. The user type then fills out the interface type with the relevant data and passes it to the procedure, unpacking another interface type returned by the procedure after invocation.

This might seem like a lot of work, but when you analyze an OO approach, you will often find a comparable number of types used to enable atomic passing to and return from a function of complex data.

Quote:
This can lead to difficulties in places of your game that you cannot plan ahead perfectly (because you will have to either drop a nice feature or work hard to adapt your code to it). By contrast, good object-oriented design strives to improve the modularity of code beyond the typical procedural modularity, and so makes code easier to refactor.

Only true if you write brain dead procedural code to begin with. A key characteristic of procedural code is its modularity, in comparison to the unstructured code ("spaghetti code" driven by gotos with no defined points of entry and exit) that preceded it.

Quote:
Another side-effect of procedural code is that unit testing becomes more difficult, because unit testing relies a lot on parametrizing the objects being tested with mock parameters, something which is not possible because procedural modules are implicit (and thus, non-reseatable) parameters of your objects.

Also false. A procedural routine is stateless, but operates on stateful objects (data aggregations) passed as parameters. Any object-oriented design can be expressed in procedural code with no loss of fidelity and quite trivially, except as concerns inheritance-based polymorphic dispatch. (Polymorphic dispatch is possible in procedural code, but it relies on, say, function pointers and writing your own dispatch mechanism.)

Quote:
Code which uses a procedural module (with a nice interface) tends to be simpler and shorter when compared to object-oriented code.

This is only because most "object-oriented code" tends to be object-happy, creating a class to represent all sorts of stateless collections of functionality (which should be namespaces/modules).

Share this post


Link to post
Share on other sites
Thanks all for replying.

@Toohrvyk
Your assumption was correct, in that Im used to just including free functions not bound to classes, namespaces etc but even still, I would class my code as still somewhat OO, as each of my subsytems are all independent of each other; the only thing they all rely on is SDL to be running.

@Mikeman
Thats basically what I assumed, cheers

@Mike2343
He's just procedurally inclined ;-) ROFL

Share this post


Link to post
Share on other sites
Quote:

I would class my code as still somewhat OO, as each of my subsytems are all independent of each other; the only thing they all rely on is SDL to be running.


That is modularity, which can occur in well designed procedural systems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi


You make valid points. I believe the core of our disagreement is my overly wide definition of object-oriented design (whereby a large portion of what you call 'good' procedural programming is to me an object-oriented design implemented with procedural tools), and that only leaves the 'bad' procedural designs as purely procedural.

Share this post


Link to post
Share on other sites
well there are 2 schools of stuff that are both normally called OO.

Object Oriented Design (data + methods to control and manipulate the data ==> object)

Interface Oriented Design (a set of methods and their promises, bound to some "thing" ==> interface)

The difference between a perfectly designed procedural library (with 1 file representing the set of functions for 1 API that applies to 1 type or more type of object or data) and a perfectly designed interface library (where 1 interface that contains the set of functions for 1 API that applies to 1 or more type of object or data) is that the procedural system does not inherently include 1 thing ... a way to treat the API as a bundle at run-time.

Basically IOP is the wedding of completely modular procedural programming with the OO concept of a v-table/"this" object. Try to sway out 23 oracle functions for 23 sql server function at run time in a C program and you will see you basically just roll-your own vtable equivelent object, which stores the method pointers, which then can be swapped out quickly and easily.

When you don't need any runtime binding / swapping the procedural system has basically no downsides against the OO or IO ones (in the above case).

Of course the main OO vs. non-OO difference is the encapsulation difference (in OO the first tier / lowest level of access and manipulation functions should be members of the class, and all higher level manipulation must only be assembled above that level (no direct access). The one fundamental thing this buys you is the ability to have more confidence in the truth of various contracts because teh OO system makes violating certain truths harder to do unwittingly (you must use pointer arithmetic or casts to bypass the member method protections. So if you don't do what you shouldn't do, you won't shoot yourself in the foot as much.

OO acts like quality control for an organization. If you trust that your toys labeled "safe for children under 2" are correctly tested at the factory, then you don't have to spend time pulling out a chemistry set to see if they contain lead, or biting on them to see if parts fall off that could choke someone. And then, as long as the toys are used in the ways they are tested again, you can be comfortable that all will be well. Such it is with well designed and debugged objects.

Share this post


Link to post
Share on other sites

This topic is 3743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this