Home > On-Demand Archives > Talks >
SOLID Design for Embedded C
James Grenning - Watch Now - Duration: 42:28
C does not have to be spaghetti code. C code can be modular and flexible if you apply the SOLID design principles. Too often design is just about personal preference. In this session we'll see that there are objective qualities that we can use to assess software design. We look at applying Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation and Dependency Inversion principles to C. SOLID gives good guidance on modularity and coupling; these principles are not just for programmers with an OO language. You can use the SOLID principles to build better C code.
Great job as always! Thanks for sharing,
James presentations are so entertaining. I wish all presentations were like this. This is hard to do with software. I will have to watch this several times.
Thanks Kevin. It takes a lot of time to make one of these. I needed it for my self-paced training as well. When I have the same thing needed for two reasons, it usually gets done.
Solid presentation! ;)
Solid comment!
Great presentation, thanks! Could you upload the slides of the presentation please ?
I added the slides I have used for a live talk on this topic. They are not exactly the slides for this talk. I hope they help.
Thanks
Hi James, thank you for this fantastic presentation. Could you provide an example of the linker binding (related to the random minute generator). If we have a.h and 2 implementations a1.c and a2.c would you then provide the split in your Makefile with some conditional logic there e.g. ifeq ($(PROCESSOR_TYPE),X86) ... or would you have any other approach?
My two cents: The conditional has to be somewhere, right? So it could be in the makefile or it could be in a script that calls different makefiles...... And, you wouldn't have a1.c and a2.c. You would keep the file names the same and place them in different namespaces (directories) and have the makefile point to the different directories.
Hi Kevin
Take a look at the reply to Andrew. Let me know if you have a follow-up comment/question.
Cheers, James
Hi Andrew,
Thanks! I'm glad you enjoyed the presentation. Thanks for the question.
I tend to separate the test build from the production build and avoid conditionals in the makefile. If I use the linker for the random minute generator I'll need three builds: one production build, a test build that uses the real random minute generator (so it can be tested), and a test build that fakes the generator so the scheduler can be tested.
The bad part about using only the linker for substitution is that when there are many functions that need tests and those functions also need to be faked (to test other parts of the system) you can get an explosion of builds.
The random minute generator made a case for using a function pointer to access one of two random minute generators, the real one and a fake one for test. Now we have one less reason to split a test build. You may have other reasons for more than one test build.
HTH
Excellent Presentation - informative and also very entertaining. Thank you!
Thank you so much for the great presentation.
Excellent presentation, thank you so much.
Nice presentation James (as always). I have found the SOLID principles to be very worthwhile, and very much worth studying and learning. SOLID isn't a "...just write the code this way..." thing. Once the principles are understood then it is clear that there is more than one way to "skin the cat" in terms of implementation, depending on the specifics of the application, resources, constraints, etc. Also, not surprisingly, SOLID and TDD get along great together.