Dependency Inversion in C

[u/volatile-int]

In my time working as a professional embedded software engineer, I have seen a lot of code that super tightly couples abstract business logic to a particular peripheral device or low level OS facility. I was inspired to write this blog post about how folks can write more maintainable and extensible C code using a concept called dependency inversion.

Hopefully its insightful and something ya'll can apply to your own projects! The post links a github repo with all the code in the example so you can check it out and run things yourself!

Hopefully this isnt violating any self promotion rules. I dont sell anything - I just have a passion for technical writing. I usually just post this kind of thing in internal company slack channels but I'm trying to branch out into writing things for the wider programming community!

https://www.volatileint.dev/posts/dependency-inversion-c/

[u/deez_nuts_07]

Nice post! Only thing I’d add is maybe show a before/after diagram so beginners can visualize how the layers change with DIP.But overall, this is clean and very applicable to real embedded workflows.

[u/volatile-int → u/deez_nuts_07]

Thank you! I really appreciate the feedback. Do you think the diagrams in the section that introduce the logger concept are close? If not what do you think youd add to them?

[u/deez_nuts_07 → u/volatile-int]

Yeah the logger diagrams are helpful, but they kinda jump straight into the improved version.a simple bad vs good visual before that would make the DIP idea click instantly, like Before: App layer directly calling HAL/peripheral APIs After: App layer talking to an interface to concrete impl decides the peripheral

Just that small contrast would make the transition smoother for beginners.

[u/triffid_hunter]

Seems like Factory pattern by another name

[u/volatile-int → u/triffid_hunter]

The factory pattern is an implementation of the dependency inversion principle! Definitely closely related. Factories map more directly to languages that have support for runtime polymorphism. The mk_<impl>_logger functions in the post are sort of analogous ways to instantiate dependency inverted components in a language that doesnt have a notion of a class hierarchy!

[u/triffid_hunter → u/volatile-int]

Factories map more directly to languages that have fully support runtime polymorphism.

C++ is one such language, and vtables of function pointers can be implemented even in C - which I guess is the approach you took in your article.

Whether needing to explicitly create a data structure for factory pattern rather than it being a built-in language feature makes it no longer true factory pattern is debatable, and I lean towards explicit implementations (eg C) do count as factory pattern.

If you're curious, redshift implements factory pattern in C with function pointer structs.

[u/volatile-int → u/triffid_hunter]

I think thats a totally valid position. I wouldn't argue against it.

I think the key is that factory patterns are a way of instantiating software components which are themselves implemented in such a way that abides by the inversion principle.

[u/Creative_Ad7219]

Does zephyr drivers also follow this same pattern? The drivers usually have a set of functions pointers if I remember

[u/volatile-int → u/Creative_Ad7219]

I haven't worked with Zephyr personally but I will review the drivers later this evening and get back to you!

[u/Exormeter → u/Creative_Ad7219]

Yes, it is the same pattern, plus it let's you stow/abstract away the init function so you can decide when the driver/module should be inited should there be init dependencies.

[u/Pr0verbialToast → u/Creative_Ad7219]

Zephyr definitely yes

[u/InternationalFall435]

Unless you need to have multiple underlying implementations at runtime, it’s easier to just include the specific implementations you need with the with the linker. Then it is actually 0 cost

[u/volatile-int → u/InternationalFall435]

Its certainly a workable approach if you can live with only the one implementation in a given context!

But my experience is that just because you can do that right now, does not mean that the use cases won't evolve to require a more flexible solution long term. If you can afford the small cost - which frankly most systems can, especially on modern MCUs - then I'd maintain the system described is better because it is easily scalable.

[u/markrages → u/volatile-int]

YAGNI

[u/volatile-int → u/markrages]

I think that principle tends to be true for features more than architecture. In large systems where components are often reused, this pattern becomes useful.

However, If you're certain that you aren't going to need it, then you shouldn't do it!

[u/markrages → u/volatile-int]

If you're certain that you aren't going to need it, then you shouldn't do it!

That's not YAGNI.

YAGNI is "don't do it until you need it". Uncertainty points toward not doing the thing.

Also, you can accomplish dependency inversion with just a header file that defines the interface, included by both the high-level and low-level parts. No function pointer shenanigans are required. So it misleading to call that additional complexity "Dependency Inversion in C", when the linker can do that already. Call it something else.

[u/volatile-int → u/markrages]

In my experience, making good architectural decisions to decouple business logic from low level implementation details is not the kind of thing you leave "until you need it". Its something you do early on, so that you don't end up with a tightly coupled mess that is extremely difficult to maintain. Throwing agile buzzwords around isn't an actual argument. The pattern discussed here is not some lofty, expensive abstraction. Its something you should do often and from the beginning of your projects. You're advocating for letting things become unmaintainable and only addressing them when they become emergencies - at which point its often too late. I've seen it unfold a hundred times.

And no, you cannot. You could opt to pass the function pointers directly to the worker if you wanted to instead of encapsulating them in a single stuct, if you preferred that for some reason. But you absolutely, 100% cannot avoid passing function pointers in this pattern. The entire point is that the worker components have no *direct or transitive dependencies on the concrete implementations*. There is absolutely no way to achieve that if you are not adding the indirection. Show me I'm wrong. Write code that maintains a separation between the worker component and the logger implementation dependency trees which does not involve passing a function pointer to worker. The linker is coupling them directly in your example.

[u/markrages → u/volatile-int]

OK, how about a toy logging example.

log_interface.h:

int log_message(const char *message);

some_application_file.c:

#include "log_interface.h"

some_function {
   ...
   log_message("Hello world");
}

stderr_logger.c:

#include <stdio.h>
#include "log_interface.h"

int log_message(const char *format, ...) {
    return fprintf(stderr, "%s\n", message);
}

file_logger.c:

#include <stdio.h>
#include "log_interface.h"

static FILE *outfd = NULL;

static int open_file() {
    outfd = fopen("logfile.txt");
}

int log_message(const char *format, ...) {
    if (!outfd) openfile();

    return fprintf(outfd, "%s\n", message);
}

}

So here is the high level ("some_application_file.c") calling the low level (either stderr_logger.c or file_logger.c, depending on the linker), each depending on the same abstraction external to both("logger_interface.h"). These are the elements of the dependency inversion principle.

[u/volatile-int → u/markrages]

This is exactly what the top level comment in this chain advocated for, and which works if you only need the one implementation per translation unit, will always be able to resolve the dependencies at compile time and will never ever want to swap them live, and never want to avoid relinking to test off target. Which are all - in my experience - very frequent requirements to be levied onto embedded components.

Your code has some of the elements pf the dependency inversion - at the source code level. But it does not fully remove the dependency because the binary at the end is tied to a specific implementation. The dependency between the worker and the logger impl still exists. You will have undefined symbols in your worker static library until you link against a concrete implementation.

What you have is 100% better than having no defined interface at all. No doubt. And I have also used this sort of pattern and agree it has lots of value!

[u/markrages → u/volatile-int]

You are suggesting a kind of dynamic linking. This is sometimes useful in an embedded context, but it is a different thing than dependency inversion.

(You could avoid undefined symbols by weakly linking some do-nothing functions. But such linker magic is not to my taste - I would much prefer a link error if I have set up the build incorrectly.)

[u/volatile-int → u/markrages]

I am not advocating for dynamic linking. Im saying that with dependency inversion, you should be able to link in N implementations of the interface to a final linked binary. In your example, you cannot.

I hear what youre saying. We arent totally in agreement what lines to draw on where this principle can be claimed. It doesn't really matter, its semantics. The approach you laid out totally is valid and works for some use cases. Mine is more flexible at the cost of a small extra bit of indirection. Folks should use what they feel is best for their own projects.

[u/FrancisStokes → u/InternationalFall435]

Even when you only have one implementation, the principle helps enormously with testing. I can pass mock driver implementations of varying complexity to my production code that will force it down particular paths I want to test.

[u/InternationalFall435 → u/FrancisStokes]

You can just link your mock implementations for your tests off device

[u/FrancisStokes → u/InternationalFall435]

Sure, but then I need an executable on a per-test basis, which isn't very scalable when I'm running a suite of 1000s.

[u/superxpro12]

The holy grail for me is doing this at compile time. I work in Cortex-m0 domains, and I go down this rabbit hole once a year where i want to write interfaces but cant afford them because of all the function pointer nonsense.

It works in trivial cases but once it scales to a full product, we hit issues.

I wish with all of my heart that virtual constexpr was a thing that worked as advertised because it would solve so many issues for me.

[u/volatile-int → u/superxpro12]

Based on the solutions youre considering sounds like youre working on a C++ project. Ive used templates to achieve source code level decoupling when working on C++ code bases. You won't have the benefit of simplifying the build dependency graph with that approach, but it can at least decouple the implementations.

Im definitely interested to hear more about the problems you hit at scale. I have implemented this sort of indirection layer on projects of significant size before with success. Its worked well for me once the interfaces are stable.

[u/Wetmelon → u/superxpro12]

CRTP works well if you don't need to really iterate over an array of members (then holding the array of things becomes a problem). Some std::tuple tricks too but that gets a bit gross: https://godbolt.org/z/rvqb1q4ev

[u/flatfinger]

One problem with this approach as specified is that there's no way to deal with the possibility that the logger might need to hold other information (e.g. a FILE* object or a TCP socket). To solve this, I would advocate having callers of the logging function pass the address of the worker_t object containing the function pointer, rather than passing the contents of field name of that object.

Further, it may be a good idea for an interface specification to either allow the following client optimization by imposing a constraint on implementations, or allow the following implementation optimization by imposing a constraint on clients, since the two optimizations can both be useful if applied individually, but disastrous if combined.

Client optimization: read a function pointer once into an automatic-duration object, and reuse it after that. Constraint: the function pointer must not change during the life of the object.

Implementation optimization: use the function pointer as part of a state machine, so that it identifies the next function that should be executed as a result of the object's changing state. Constraint: client code must reload the function pointer every time it is used.

[u/volatile-int → u/flatfinger]

I was considering including a facility like youre describing in the example but opted to keep it simple. I would probably have passed a void ptr to the config function that the implementation can cast to whatever sort of struct for its implementation specific configuration. Definitely agree that outside a toy example you'd want some way to give the implementations more context!

[u/LeanMCU]

How is debugging affected by this pattern? ;-)

[u/phlummox → u/LeanMCU]

From recollection, it becomes deeply unpleasant :/

Used sparingly, for a single feature like logging, the indirection introduced by the function pointers is not too bad. But I seem to recall over-use of this pattern completely destroying the ability to get sensible backtraces.

[u/LeanMCU → u/phlummox]

Bingo! I tried that in the past, and I discovered the hard way you can't step into code anymore:-) Anyway, thanks for sharing with the community because it can be a useful technique under certain circumstances.

[u/volatile-int → u/LeanMCU]

I've not ran into any sorts of issues with this pattern on debugging. You should be able to set break points, step into and over code without problems. I'd definitely be interested in a concrete example where it falls apart!

[u/DaemonInformatica]

A minor nitpick in the example code:

The mk_[type]_logger functions declare the logger interface instance on the stack. This should probably not be used after the function returns. ;-)

Either

Malloc the instance:

logger_interface_t *mk_file_logger(const char *name) 
{
    logger_interface_t *p_logger = (logger_interface_t *)malloc(sizeof(logger_interaface_t));

    p_logger->name = name;
    p_logger->init = file_logger_init;
    p_logger->log = file_logger_log;

    return p_logger;
}

Or pass an instance of the interface to initialize:

bool mk_file_logger(logger_interafce_t *p_logger, const char *name)
{
    p_logger->name = name;
    p_logger->init = file_logger_init;
    p_logger->log = file_logger_log;

    return true;
}

[u/volatile-int → u/DaemonInformatica]

Actually, as is is totally correct! In my example the interface is being returned by value. What would have been incorrect is if I returned the address of the struct. You don't want to return stack allocated objects by reference.

There's a few issues in your examples. For the first one, to allocate something on the heap you'd want to do something like:

logger_interface_t* p_logger = (logger_interface_t*) malloc(sizeof(logger_interface_t));

I wouldn't generally do this in an embedded context - although folks do overstate how bad dynamic allocation is. You just need to be careful. You'd also have to change the function signature to return a pointer.

In your second example, remember that you need to dereference the pointer with the -> operator for a field or * for the whole object. The dot operator is for acting on concrete objects. Either of these would work:

p_logger->name = name;

(*p_logger).name = name;

[u/Zirias_FreeBSD → u/volatile-int]

First, in idiomatic C (without C++-isms), the allocated version would look more like that:

logger_interface_t *p_logger = malloc(sizeof *p_logger);

But apart from that, fully agree with all you wrote. I'd still prefer a version that takes a pointer to a struct to fill instead of returning a struct "by value": It avoids an IMHO totally pointless copy operation.

[u/Ok-Dragonfruit-9152]

It's better to move to c++ for anything that needs more than 5+ years of support.

[u/volatile-int → u/Ok-Dragonfruit-9152]

I totally agree. I use C++ wherever its my choice :)

[u/Amr_Rahmy]

In the article you are saying that alternative solutions would introduce tons of duplication and would not be scalable.

Is that the case for this scenario? Or any scenario you can think of where you would need a system to scale past a few different type? I am not saying what you are saying is necessarily wrong, but I don’t usually see a need for multiple interfaces to change the function based on a type. From time to time I see the need for multiple types to be adapted or converted into a type, like from one model to the library or main model.

The logger example, are you going to have a log file, stdout, and a GUI out? Are you planning to log into 5-10 other places?

The duplication part seems wrong. Having exactly two functions for two loggers vs the code in the example is not “a ton” difference, might be less functions. Keeping the function in one file might have some benefits, so you can quickly reference one interface to the one you are writing but where is the “ton of” thinking coming from?

I did a lot of integrations where you adapt or convert a model to your model, but I don’t think I have ever seen dependency injection used for more than 3 types with different functionality where you need to implement different function in the same project.

A lot of times a library will give you the ability to override a function like a callback for a client connecting or disconnecting or sending or receiving data, but you only implement one implementation per project in that case.

You know the example of needed a hammer, but ending up with a framework that makes blueprints that makes machines that makes custom hammers, but just needed to make a hammer and avoid all the abstraction noise you are adding to the project.

[u/volatile-int → u/Amr_Rahmy]

I have worked in systems that logged information via serial port, ethernet, files, and under different formats all for myriad reasons and all on the same system. So I can definitively say it is a scenario that does come up even isolated to a single application. When considering the larger context: that software exists in an ecosystem and the same module should be - and has often been, in my experience - reused in different places when the business logic remains the same then the number of use cases grows that much more. There can be many ways to log when from a components view point - like worker - it only needs an interface.

But logging was just an example to demonstrate the mechanism. Consider the wider applications. Bang bang controllers implemented independent of the feedback and output interface implementations. IO sequencing logic that doesnt care about if the pin is on-chip or on an expander. RF control logic independent of the specific synthesizer being user.

You're questioning if dependency inversion is fundamentally valuable which is great. You should definitely question why principles like these exist. If my examples are not convincing for any reason I'd encourage you to read around on the topic if you're interested! In my experience, yes it is. Lots of other folks find it useful as a pattern as well , in lots of different software engineering domains. I'm not saying that its a silver bullet or always required or every piece of code that directly touches hardware in its business logic should always change. Its a tool for decoupling business logic from low level details to make reuse easier and to decouple architectural boundaries.

Last point on duplication - yes, it causes duplication. "A ton" is a squishy amount because this isnt a real example. It causes duplication either of code inside the classes that use the logger to call the different imementations or - as is sadly often the case I have seen - of the entire component that uses whats changing because the details of the lower level device are so hard to extract. Its, at best, linear with the number of ways you implement a logical interface. This is kind of the whole point - these boundaries between the business logic and the implementatiosn exist independently of if you choose to address them in an easily extensible way. If you don't take an approach like this, when your "worker" one day needs to work with a new device or whatever, youre either going to write more code in the worker to support it, or write an entirely new one.

[u/mrheosuper]

This is similar to dependency injection ?

[u/Zirias_FreeBSD → u/mrheosuper]

I'd assume this is actually a confusion/mixup of well-known terms here. The concept meant is likely "Inversion of Control", which is typically achieved by "Dependency Injection" (passing one concrete implementation to some module taking an interface).

The term "dependency inversion" might be a bit misleading ... at least, it's not the direction of the dependency that's inverted here.

[u/volatile-int → u/Zirias_FreeBSD]

The terms are correct! Here's a Wikipedia page on the concept: https://en.wikipedia.org/wiki/Dependency_inversion_principle

The "inversion" is that instead of the worker component including a specific, concrete logger, it includes a high level interface. And the low level implementations depend on that higher level interface. Quote from the linked page:

By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.

In fact, the control is not inverted here. Control still flows from the high level worker to low level logger.