Established names of OOP design styles in C [closed] - c

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
In C, when implementing functions which work on some data, I can think of at least the following commonly used styles of how to implement them:
Style 1: The simplest one. User calls functions directly and provides pointer to data as argument.
typedef struct
{
int data;
}SomeStruct;
void setData(SomeStruct *s, int value)
{
s->data = value;
}
// construction
SomeStruct s;
// usage
setData(&s, 123);
Style 2: User calls functions through function pointers, but still needs to manually provide pointer to data.
typedef struct SomeStruct SomeStruct;
struct SomeStruct
{
void (*set)(SomeStruct*, int);
int data;
};
void setData(SomeStruct *s, int value)
{
s->data = value;
}
// construction
SomeStruct s;
s.set = setData;
// usage
s.set(&s, 123);
Style 3: User calls functions through function pointers and doesn't need to provide pointer to data manually.
typedef struct SomeStruct SomeStruct;
struct SomeStruct
{
void (*set)(int);
int data;
};
#define MAX_INSTANCES 2
SomeStruct structs[MAX_INSTANCES];
void setData(SomeStruct *s, int value)
{
s->data = value;
}
void setData0(int value)
{
setData(&structs[0], value);
}
void setData1(int value)
{
setData(&structs[1], value);
}
// construction
structs[0].set = setData0;
structs[1].set = setData1;
SomeStruct *s0 = &structs[0];
// usage
s0->set(123);
In style 2 and 3 the data and setData can be hidden from the user, but I omitted this here for the sake of simplicity.
The question is: Are there established names for these styles?

Answer 1

Style 1 is traditional C.
Style 2 is the beginnings of Object-Oriented C. If it has a name, it is "method implementation pattern"
The problem is that you have an improperly named method for Style 2.
void SomeStruct_setData(SomeStruct *s, int value)
{
s->data = value;
}
or
void SomeStruct_data(SomeStruct *s, int value)
{
s->data = value;
}
are a bit better, because now it signals the intention that SomeStruct is being treated like an object.
Fancier approaches that emulate more of an object oriented system exist. They typically provide (in the header)
struct SomeStruct;
and place the private struct within the SomeStruct.c file. This prevents the ability to access the fields directly, forcing all who modify SomeStruct to use the SomeStruct_*(struct SomeStruct*, ...) methods. Often these approaches will use typdefs to present a slightly renamed struct struct SomeSturct_s* as SomeStruct.
Style 3 is one of the many variations that might be called "vtable implementation" in C. It is often a precursor to polymorphism
Remember that C doesn't have a true polymorphic typing system, so the actual types generally get converted to void * in implementation; but, through patterns of all the object struct fields, you can embed the type into to struct (typically done with a uint32_t or enum, sometimes done with more sophisticated type-handling routines).
In any case, eventually you will need a function that changes behavior, and that function is implemented as a function pointer with many different C-style functions providing the behavior(s), and the type assignment / handling choosing the correct functions to assign to the struct to implement the type's behavior. Basically this is a mini-vtable, if you want to translate it into C++ terms.
Some systems start off with switch statements based on the object type, typically read from the struct (in a fixed location field required by every object struct). Eventually they realize they are just a switch statement that passes the parameters to one method based on the base-class type. By using a function pointer and leveraging construction time assignment, the switch statement can be optimized away.
Object Oriented C is a thing, but it is not a standard.
There are many times when one wants to use Object-Oriented C. The maintenance conveniences and clear delineations for testing are typically the drivers that have people choose this approach. That said, the actual system will resemble a lot of "you write the Object-Oriented simulation in C" and you don't often complete all of the features of whatever OO system you are emulating.
To make this easier, there are a number of approaches:
Write a mini-language that expands into C. This was the original approach of C++, until they decided that the benefits of type checking all the way through the compilation phase was worth combining the pre-processing language with the compiler.
Use a pre-built Object Oriented C environment. GNOME has already built their GObject library, and while the syntax and macro choices may take some getting used to, the entire library is complete, robust, and tested. This "C" as the fundamental layer, allows GNOME to be ported to a few more platforms that its traditional competitor KDE, which requires a C++ compiler (available on fewer platforms).
Refactor your code into reusable components, to speed the construction of your less-than-full-featured OO system. By making the components reusable, either through macro expansion or including methods, you will speed up the creation of new objects, and spend less time debugging them to verify they work as objects.
The first steps are very easy to implement (non-dynamic methods, vtables without sophisticated built-in type checking) but it gets harder as you go along (but not too hard). I've built a system (for fun) that even correctly implements "try / catch" semantics with macros that use the setjmp and longjmp C functions to handle thrown objects with polymorphisim, complete with re-throws, re-catches, and re-handlers following a Java-like behavior.
If you like to play with these kinds of toys, I suggest you get good at standing up unit tests in C, using tools like autotools or its equivalent; because, at least in the early stages, you will be finding that the most basic approach won't capture all the behavior needed as you near completion, and having a testing suite will prevent you from breaking your prior work.