Ubuntu-gr Forum

gtk_tic readme file έγραψε:
...
Environments
------------

The general idea was to separate the GUI from the game itself, so the action takes place mostly in two environments: the gaming environment, represented by the custom type: Game, and the GUI environment, represented by the custom type: Gui. Those two environments are abstract siblings inside the general environment of the program, represented by the custom type: GenEnv.

The general environment is responsible for controlling the interaction between the game and the GUI environments, while performing higher level tasks. As you can see in the source code, things didn't go exactly as intended, because as I explained above I was too lazy to thoughtfully prepare the design of the program before getting to code it. As a result, I've ended up with a few stray functions, not clearly belonging to any distinct environment. I left them "floating" around, tagging their names with the prefix "util_" (meaning: utility functions).

Speaking of prefixes, gui related functions have their names prefixed with "gui_", while game related functions have their names prefixed with "game_". Functions related to the general environment, have their names prefixed with "env_".

The gaming environment ( Game ) has a child environment, represented by the custom type: GamePlay, with related functions having the "gameplay_" prefix in their names. This GamePlay environment is not what its name may suggest at a first glance: it does not refer to the general game play. Instead, it refers to a single round inside a game (a single play). So a perhaps more intuitive name for this custom type would be something like: Round, but I started the code using Play as the name, later changed it to GamePlay, and I figured that once explained it is not that misleading after all.

There is more data-structure nesting going on in the source code (for example the custom types PlayBoard and Player, belonging to the GamePlay environment, or the custom types GamePrefs and GamePlaystats belonging to the Game environment) but those can be hardly thought as complete environments by themselves. So just think of them simply as interior parts of the basic environment they belong to.


Object Oriented Approach
------------------------

The above design is an Object Oriented approach, and actually most of those functions do operate on pointers to abstract objects, which are passed at the start of the argument list of the functions. So "env_" functions have their 1st argument being of type GenEnv *, while "game_" functions have their 1st argument being of type: Game *, and "gameplay_" functions have their 1st argument being of type: GamePlay *, and so on.

Exceptions to this OO convention are the "util_" and "debug_" functions, for the reasons I explained earlier (stray functions).

Proper OOP in C is usually implemented with classes being structures, containg methods as pointers to functions inside each class struct. The 1st argument of those functions is a pointer to the type of the class. Then, encapsulation is achieved via splitting the code into separated .c files, thus hiding the internal implemnetation of private stuff. Public access is given via one or more header files, which only expose the needed abstractions to the programmer. Class constructors & destructors are implemented as separate, public functions (unless one wants to push things to the exterme, building a fully managed environment for his program).

If I was implementing all the above in such a small project as this one, then a proper suffix for its name would be something like "Overkill to Death and Beyond" instead of just "Overkill"!

...