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

In this lesson, we’ll step outside the domain of standard C and investigate a pattern for event-driven
applications. The **Reactor** pattern decouples different responsibilities and allows applications
to demultiplex and dispatch events from potentially many clients.

# The case of many clients
Diagnostics of individual subsystems are gathered in one central unit to simplify the maintenance of large systems. Each subsystem connects to the diagnostics server using **TCP**. As **TCP**
is a connection-oriented protocol, the clients (the different subsystems) have to request a connection at
the server. Once a connection is established, a client may send diagnostics messages at any time.

The brute-force approach scans for connection requests and diagnostics messages from the clients
one by one as illustrated in the activity diagram in Illustration 1.

Even in this strongly simplified example, there are several potential problems.  Several unrelated responsibilities have been built into one module by intertwining the application logic with the networking code and the code for event dispatching. Such a design is likely to lead to serious **maintenance**,
**testability**, and **scalability** problems by violating a fundamental design principle.

In this lesson, we will investigate a pattern for event-driven applications.



Investigate a Pattern for Event Driven Applications

In this lesson, we will investigate a pattern for event-driven applications.

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

Investigate a Pattern for Event Driven Applications

Implementing Reactor

The case of many clients