Thread: Help with non object oriented design?

Originally Posted by Twk Amz;

I learned programming with oo languages, so since I moved to c, I wasn't able to program without trying to "emulate" oop(creating a struct and a set of functions to act upon this struct, for example: "createPlayer(Player * this)", "movePlayer(Player * this)").

From all the C based API's I've looked at, that is a pretty standard thing. I'll give some examples...

From SDL, I can create or destroy an SDL_Window structure with calls:

Code:

SDL_Window* SDL_CreateWindow (const char* title, int x, int y, int w, int h, Uint32 flags);
void SDL_DestroyWindow (SDL_Window*);

From Win32 I can do a similar thing by first initializing a WNDCLASS structure, then registering it and finally calling CreateWindow to be passed an actual handle to the window. Like most of the 'handle' structures in Win32, this handle is opaque (it's just a void*).

There are also many examples with the Linux networking libraries, just a random example might be the struct ifreq, which can be used to get and set many states of the interface:

Code:

struct ifreq ifr;
strcpy(ifr.ifr_name, "wlan0");
ioctl(socket, SIOCGIFFLAGS, &ifr); // magical adhoc socket :P

Originally Posted by Twk Amz

I know that c is procedural, and I don't want to use this (hackish) technique for designing programs.

I've seen other people say similar things, but I think it's more correct to say that C supports procedural programming in a relative sense. It also has facilities to express things in more Object Oriented or even Functional terms.

Originally Posted by Twk Amz;

So, the question is: how should I design my modules/programs in c? how should I be thinking about modules and what about entities(classes)?

I think your original examples of design should be sufficient. Just because a language caters more to a procedural style doesn't mean you shouldn't use organizational tools like encapsulation, abstraction, ect. You can group structures and functions into headers and source files based on their functionality in a way that makes sense.

The most important thing (IMO) isn't that you adhere strictly to a given paradigm, but that your code is organized and abstracted well enough to make it as reusable and sturdy as possible.

I would also suggest to implement internal types hiding when designing your APIs
In the public header you declare the HADNLE type which will be passed to all your API functions

In the C (or private h-file that is not included by the external code) you declare your actual type struct
inside your code you cast the handle to actual type and work with it - thus preventing modifications of internal type fields by the external code directly without usage of API calls

AS for naming conventions - I prefer to emulate c++ scheme by using

ModuleTypeMethod names like

Code:

int GamePlayerCreate(PLAYER_HANDLE *hPlayer);
int GamePlayerMove(PLAYER_HANDLE hPlayer, int x,int y);
void GuiDisplayRedraw(DISPLAY_HANDLE hDisplay);