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

Although the mechanisms used to implement them are related, there are differences between these two
patterns. The main difference is in the notification mechanism. As a Subject changes its state in an
**Observer** implementation, all its dependents (observers) are notified. In a **Reactor** implementation, this relationship is one to one – a detected event leads the Reactor to notify exactly one dependent
(```EventHandler```).

One typical liability of the **Observer** pattern is that the cohesion of the subject is lowered; besides
serving its central purpose, a subject also takes on the responsibility of managing and notifying observers.
With this respect, a Reactor differs significantly as its whole raison d’être is to dispatch events to its
registered handlers.

The main consequences of applying the **Reactor** pattern are:
* **The benefits of the single-responsibility principle**: By using the **Reactor** pattern, each of the responsibilities above is encapsulated and decoupled from each other. The design results in increased cohesion, which simplifies maintenance and minimizes the risk of feature interaction. As the platform-dependent code for event detection is decoupled from the application logic, unit testing is greatly simplified. It is straightforward to simulate events through the EventHandler interface.

* **The benefits of the open-closed principle**: The design now adheres to the open-closed principle. We can now add new responsibilities to new event handlers without affecting the existing event handlers.
* **Unified mechanism for event handling**: Even if the **Reactor** pattern is centered on handles, it
may be extended for other tasks. ***Pattern-Oriented Software Architecture*** [(Schmidt et al.)](https://www.educative.io/courses/software-design-patterns-c/conclusion) describes
different strategies for integrating the demultiplexing of **I/O events** with timer handling. Extending
the Reactor with timer support is an attractive alternative to typical platform specific solutions
based upon signals or threads. This extension builds upon the possibility to specify a timeout value
when invoking the synchronous event demultiplexer (for example, `poll()` allows us to specify a timeout with a resolution of milliseconds). Although it will possibly not suit a complex real-time system, a Reactor-based timer mechanism is easier to implement and use than a signal or thread-based solution. It tends to avoid re-entrance problems and race conditions.
* **Provides an alternative to multithreading**: We can typically avoid multithreading and blocking operations in the concrete event handlers by using the Reactor pattern. As discussed above, a multithreaded solution does not only add significant complexity; it may also prove to be less efficient in terms of run-time performance. However, as the Reactor implies a non-preemptive multitasking model, each concrete event handler must ensure that it does not perform operations that may starve out other event handlers.

* **Trades type-safety for flexibility**: All concrete event handlers are abstracted as **void***. When
converting a void-pointer back to a pointer of a concrete event handler type, the compiler
doesn’t have any way to detect an erroneous conversion. We fight this potential problem by implementing the **Observer** pattern, which has the same solution as **Reactor**. Define unique notification functions for each different type of event handler and bind the functions and event handler together using an EventHandler structure as described in [Listing-1](https://www.educative.io/courses/software-design-patterns-c/implementing-the-reactor-pattern-part-1).

In this lesson, we will compare reactor and observer patterns  and explain the consequences of using the reactor pattern.



Consequences and Comparison 

In this lesson, we will compare reactor and observer patterns  and explain the consequences of using the reactor 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

Consequences and Comparison

Comparison of Reactor and Observer

Consequences