Gain insights into software design patterns in C, explore their implementation, discover underlying principles, and learn to build a vocabulary for better communication and coding practices.

c.tar.gz

main+customer.c

main+customer.c-copy

watches

customers

observer

Reactor

Reactor-copy

observer-copy

Software design patterns are a valuable tool in any software developer's skill set. However, most design patterns are described in the context of an object-oriented programming language such as C++ or Java. The C language is sadly absent in the pattern literature. This course is here to change that by demonstrating that it is possible to use patterns in C programs and how it adds benefits to C programmers. You will learn why design patterns are more of a communication tool than technical solutions, and how patterns let you build and share a common vocabulary that simplifies communication.

The course presents a number of patterns and explains how to implement them in C. Each pattern is introduced via the problem it solves and the domains where the pattern can be used. We also discuss the underlying design principles as well as the trade-offs when applying the pattern. Finally, the course covers a set of coding idioms that will guide you when applying design patterns in C.

Software Design Patterns in C

Every non-trivial program passes through several different states during its lifecycle. Describing
this lifecycle as a finite state machine is a simple and useful abstraction. This lesson investigates
different strategies for implementing state machines. The goal is to identify mechanisms that let the code
communicate the intent of expressing the problem as a finite state machine.

Consider a simple, digital stop-watch. In its most basic version, it has two states: started and stopped.
A traditional and direct way to implement this behavior in C is with conditional logic in the shape of
 **switch/case** statements and **if-else** chains.

In this example, the digital stop-watch is implemented as a First-Class ADT.

typedef enum
{
    stopped,
    started
} State;

struct DigitalStopWatch
{
    /* Let a variable hold the state of our object. */
    State state;
    TimeSource source;
    Display watchDisplay;
};

void startWatch(DigitalStopWatchPtr instance)
{
    switch(instance->state) 
    {
      case started:
          /* Already started -> do nothing. */
          break;
      case stopped:
          instance->state = started;
          break;
      default:
          error("Illegal state");
          break;
    }
}

void stopWatch(DigitalStopWatchPtr instance)
{
    switch(instance->state)
    {
      case started:
          instance->state = stopped;
          break;
      case stopped:
          /* Already stopped -> do nothing. */
          break;
      default:
          error("Illegal state");
          break;
    }
}



This is a superficially simple solution. While the coding construct may be simple, the approach
introduces several potential problems:
* **It doesn’t scale:** In large state machines, the code may stretch over page after page of nested
conditional logic. Imagine the true maintenance nightmare of changing large, monolithic segments
of conditional statements
* **Duplication:** The conditional logic tends to be repeated, with small variations, in all functions that
access the state variable. As always, duplication leads to error-prone maintenance. For example,
simply adding a new state implies changing several functions.
* **No separation of concerns:** When using conditional logic for implementing state machines, there is
no clear separation between the code of the state machine itself and the actions associated with the
various events. This makes the code hide the original intent (abstracting the behavior as a finite
state machine), thus making the code less readable.

In this lesson, we will explain the different strategies for implementing state machines.

Introduction to Pattern in C

The First-Class ADT Pattern

The State Pattern

The Strategy Pattern

The Observer Pattern

The Reactor Pattern

Idiomatic Expressions

Conclusion

Different Strategies for Implementing State Machines

Traditional Solution with Conditionals