hi, The other day I was bored and I started thinking about ways to make current programming languages better. I started thinking about my experiences coding and where I personally got into trouble in my projects. It seems to me that you could divide most OO programs into two parts. Lets call one part Object design/implementation. I like to call the other part - the part where you actually "do something" with objects- procedural coding. I think that languages today have all but perfected the first part of OO design. Where we are really lacking is in the area of procedural programming. I think that most programmers will agree that no matter how perfect your objects are.....you can still screw up with the procedural code. Why is this so easy to do? M-O-D-U-L-A-R-I-T-Y. I think it makes sense to dive one step further into OO design.....Beyond objects. I think that related functions could be modularized behind an interface. I like to call this interface a "sevice". Let me make an analogy to make this clearer. A class is to a data type what a service is to a group of related functions AND all of the variables used in those functions...you say "but that sounds just like a class!"....bear with me here. Ok now let me show you what made me think of this and how my idea would help. Lets come up with a task and write the first few lines of a program. Ill use a tetris like game as an example. (NOTE: this is REALLLLLY simple!) .....its crap like this that frustrates me: // pretend like this is the file that has Winmain in it. // It COULD be another file though #include "someclassdefs.h" // lots of programmers like to make their dx objects // global.... LPDIRECTDRAW7 lpdd; LPDIRECTDRAWSURFACE7 pieces[10]; LPDIRECTDRAWSURFACE7 lpddsPrimary; LPDIRECTDRAWSURFACE7 lpddsBackground; // some other common things I see declared globally Point playerPos; Grid playingField; ErrorFile gameErr; //...ok ive already done enough to make my point Now I want you to pretend you have no clue what this program does. Read the first few lines and think about what this program is gonna do.... You know you see direct draw objects. As game programmers you know you might be doing some graphics, but looking at all the objects together as a group they really seem unrelated or grouped with no real logic. You really cant assess how they are going to be used together. Now imagine doing something like this in a .h file: service GraphicsHandler : // all of those direct X objects from above would // go here { // the objects declared after the : above would be global // to the functions between the { }''s but nowhere else // every function in this service would go here void drawPieces(); void changeResolution(int, int, int); void etc(). // Note: there could be and most likely WOULD be other class // definitions here too. }; then the first example would look something like this when you got through. #include "somefile.h" service GraphicsHandler; service InputRetriever; service ErrorWriter; blah Winmain( blah, blah.... ) { // you dont have an "instance" of a service. A service would // be a cookie cutter that you can use to accomplish a // task. you would just declare the // fact that you are using a service. Therefore a sevice would // not be used when you need to keep an instance of // data....use a class for that! Thats what they''re there for! //... somewhere in your code GraphicsHandler.ChangeResolutions(....); InputRetriever.GetKeyBoardState(reference); } I wanna defend one point everyone is obviously gonna be thinking. "Why couldnt you just make GraphicsHandler a class?" Well...you could. I understand that. However, in some situations it DOES NOT MAKE SENSE to have an object. Just look at the typical naming scheme for an object. Almost all of the time an object is given a noun name. Ex - Point, Grid, Car, you get the idea. It makes more sense to specify something associated with action. For example....would it make sense to have an object called Birth? Would it make sense to have an object called Attack? It WOULD, however, make sense to have a service called Birth or a service called Attack. There is obviously more to think about here than ive covered in my initial thoughts and im sure something in here is flawed:-) However....this OBVIOUSLY makes the code more readable. Instead of having stray function calls you now have a logical grouping associated with a function. IT also makes it easier to find the freakin definition for a function. Let me make a point....if you wanna find the implementation to say.... BlitPieces() and every variable used in that function- where would you look huh? but if you see GraphicsHandler.BlitPieces() you know EXACTLY where to look! I only covered the point of modularity...but I think with modification and more thinking this could be a really useful tool in programming. Its use could go far beyond that of modularity. I would like anyone''s thoughts on this. I know that if this idea is read and improved upon and actually implemented, the programming world would be greatful! happy new years, skitzo_smurf

Your idea still seems really procedural to me (its a good one though!)
What you seem to want is a framework, a collection of object designed to work together. Also read about ''mediators''.


P.S. Check out www.auran.com and look for Jet.
I don''t think a good OOD would have the frame buffers as globals.
OTT: How viable is delphi for OOD?

Magmai Kai Holmlor
- The disgruntled & disillusioned

As far as i see it C++ already gives you what you want...namespaces!

you can just declare functions/variables as part of a namespace, and then use that one in your main file

In my own code, I actually instantiate primary graphics surface class, just like you directly call one method of it (GraphicsHandler.ChangeResolutions). It''s not really big deal to create objects, it only makes your code more scalable. Having some global GraphicsHandler is bad idea when thinking of scalability. For instance the code I use to test my gfx classes looks following:

void demo(O3_surfacePrimaryBase &surface_)
{
// some platform independent gfx code goes here...
}

int WINAPI WinMain(HINSTANCE inst_, HINSTANCE prev_, char *cmd_, int show_)
{
// create DirectX 7 triple buffered 3D primary surface in 1152x864x32bpp resolution
O3_DX7surfacePrimary prim(1152, 864, 32, 2);
demo(prim);
return 0;
}

Now, as you can see, I can instantiate OpenGL primary surface in WinMain() and pass it to the demo-function without changing the demo function at all. If you got some global GraphicsHandler you can''t do that nor for instance have several windowed primary surface in one application without explicitly declaring functions in GraphicsHandler which handles such case.

When using objects, you also got automatic destruction mechanism, which helps you great deal and you can write far more robust code. For instance when prim runs out of scope, it automaticly closes the surface and releases the resources.

Cheers, Altair


"Only two things are infinite, the universe and human stupidity, and I''m not sure about the former." - Albert Einstein