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

One of the State pattern strengths is that it encapsulates all state-specific behavior, making the state machine easy to extend.

* **Adding a new event:** Supporting a new event implies extending the ```WatchState``` structure with a
declaration of another pointer to a function. To add a new default
implementation of the event to ```WatchState.c```, use the mechanism described above. This step protects existing code from changes;
the only impact on the concrete states is on the states that intend to support the new event, which
have to implement a function of the correct signature to handle it.
* **Adding a new state:** The new, concrete state has to implement functions for all events supported
in that state. The only existing code that needs to be changed is the state in which 
we'll transition to the new state. Please note that the State pattern preserves one of the benefits of the
table-based solution: client code, i.e., the context, remains unchanged.

The states in the sample code are stateless, i.e., the ```WatchState``` structure only contains pointers to  reentrant functions. Indeed, this is a special case of the State pattern because **“[i]f State objects have no instance
variables […] then contexts can share a State object”** ([Gamma, et al](https://www.educative.io/courses/software-design-patterns-c/conclusion)). Don’t forget **Joshua Kerievsky’s** advice that **“it’s always best to add state-sharing code after
your users experience system delays and profiler points you to the state-instantiation code as a prime
bottleneck.”**

In this lesson, we will explain the benefits and consequences of using the State pattern.

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

Benefits and Consequences of Using State Pattern

Extending the State Machine

Stateless States