Namespace versus Class
Author
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
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]
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]
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.
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.
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.
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.
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.
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 ;-)
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).
Author
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
@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
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
