POSIX API and SOLID design principles

Question

Although SOLID design principles are mainly applied to object-oriented systems, there are some SOLID concepts that can be applied to procedural programming, such as SRP or DIP. But when I studied some functions that are available in the POSIX API, I noticed that some principles are not respected, even though it could be so.

I'll take as an example SRP, and the system call sigaction :

• SRP states that, in our case, a function must have a single responsibility, which means that changes in a single part of the specifications of our system is the one thing that could change the specifications of the function.
• sigaction is a system call used to change the action taken by a process when it receives a signal.

sigaction can be used to install a basic handler of the form :

void (*sa_handler)(int)

Meaning that the handler receives just the number of the signal to perform its action. The system call can also be used to install a handler of the form :

void (*sa_sigaction)(int, siginfo_t*, void*)

Which let us gain more information about the handled signal. Both forms are installed with the same system call, thanks to flags that are placed by the caller.

In my point of view, sigaction violates the SRP principle, because it has the responsibility to implement both types of handler installation.

So my question is : does POSIX API violates SOLID principles, if so, why ?

Answer 1

With all due respect, I think your example is on thin ice (it also ignores the D in SOLID).

POSIX might be violating the SOLID principles (or it might not)... but on the other hand, POSIX has a mature understanding of what can be separated and what belongs together (an understanding that comes from practical use).

In other words, the question is about the scope of "what is a single responsibility?", and POSIX has decades of experience that help it draw the line.

In your example, you state that sigaction has to implement both types of something, but that is a fallacy.

sigaction has a single responsibility - it needs to register a callback. The callback type is irrelevant really, since the responsibility is in the "registering".

If an Array push function would be type agnostic, would it violate the SRP principle? No. It would handle a single responsibility - pushing to the Array. Same here.

If I were to follow your logic, implementing a different function per callback type, I will find myself writing the same code over and over with slight variations - this is a violation of the DRY principle and it's a clear sign that these functions share the same responsibility and should be unified.

Answer 2

Aside from these principles being matters of opinion, POSIX predates SOLID by decades. It also mostly documents and formalizes existing practice rather than reinventing things from the ground up. Design-by-committee tends to be a much bigger problem than violation of pedantry like SRP, so this is almost surely a good thing.

Note that some of the interfaces actually designed by POSIX do heavily follow OOP design principles, often in ways that introduce flaws. For example posix_spawn failed to be an AS-safe replacement for fork and execve because it depends on attribute object creation. The POSIX threads interfaces also borrow heavily from OOP in ways that usually don't break anything but make them gratuitously painful to use.

Answer 3

We don't really have any idea about the purpose, i.e., the single responsibility, of the particular implementation of sa_sigaction that you call.

If I had to guess, though, I would expect that the sa_sigaction implementation is part of an interface module that implements that POSIX API on top of the lower-level OS-specific capabilities, and that the one responsibility of the sa_sigaction function is to implement that specific part of the POSIX specification.

In other words it's an adapter pattern object, and it has a single responsibility.

Perhaps you meant to say that the POSIX API specification violates SRP... maybe but that hardly matters. SRP is for making your system resilient to changing requirements. As an ancient API standard, POSIX isn't getting a whole lot of new requirements. It essentially documents how things were done in the past, and the facts of history don't change.

Answer 4

does POSIX API violates SOLID principles?

Yes. POSIX is decades old and written by many software engineers with the support of IEEE. SOLID is relatively new (in comparison) and was written by some guy named Bob.

POSIX is more mature, and the people behind it realize that have neat little acronyms (ie. S.O.L.I.D.) can't account for all the small exceptions in software engineering.

If you ask me, SOLID is the one violating POSIX.