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

State is useful for more complex state handling when there's application logic associated with each state.

Conditional logic is perfectly fine for simple scenarios with 2 or 3 possible states.

Always go for the State patterns and avoid conditional logic since each branch adds complexity

When should we consider the State pattern? 

When should we consider the State pattern?

One trade-off with the State pattern is that you end up with more compilation units (e.g., files) and less compact code. 

One trade-off with the State pattern is that you end up with more compilation units (e.g., files) and less compact code.

Complex state handling can become opaque and hard to fit in one's head when reasoning about the code.

 The state handling becomes implicit, meaning the actual state is a combination of different variables, making it hard to debug and maintain the code.

It lacks a clear separation between the code of the state machine itself and the actions associated with the various events. 

Encourages code duplication as it's easy to repeat the same logic in multiple places inside larger conditional chains.

In many programs, state transitions are often implicit in the design in the shape of conditional logic. It's a superficially simple solution that's easy to understand for simple state handling. However, expressing state handling with conditional logic doesn't scale well. What are the main scaling challenges?

In many programs, state transitions are often implicit in the design in the shape of conditional logic. It’s a superficially simple solution that’s easy to understand for simple state handling. However, expressing state handling with conditional logic doesn’t scale well. What are the main scaling challenges?

By implementing self-modifying code where we rewrite the part of memory representing our program code.

By letting the actual state be a pointer to a function. Changing state simply means pointing to a different function. 

By using a lookup table for each state transition.

The key idea in the State pattern implementation is to represent each state as a distinct object. A state transition means changing the reference from one of the concrete states to another; our state representation appears to change behaviour at run-time. How is this achieved in the C language?

The key idea in the State pattern implementation is to represent each state as a distinct object. A state transition means changing the reference from one of the concrete states to another; our state representation appears to change behaviour at run-time. How is this achieved in the C language?

Our implementation of State lets us initialize our state representation with a default implementation for each event. That way, there's always a fallback with the controls built into the design.

A valid state representation can never be `null`, and hence no additional checks are needed.

Since the state implementations themselves are stateless, we cannot modify any data. This means we can never corrupt our program state.

When modeling our code as a finite state machine, there are always going to be certain events that aren't valid in a given state. How does the State pattern help in writing robust and secure code?

When modeling our code as a finite state machine, there are always going to be certain events that aren’t valid in a given state. How does the State pattern help in writing robust and secure code?

Test your knowledge of the State Pattern concepts with this quiz.

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

Quiz: The State Pattern