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

# Consequences
The main consequences of applying the **Observer** pattern are:

* **Introduces loose dependencies**: As the subject only knows its observers through the Observer interface, the code conforms to the **open-closed principle**. We may introduce any number and any types of observers that support the Observer interface by avoiding hard-coded notifications.  New behavior, in the form of new types of observers, is added without modifying existing
code. The loose dependencies provide a way to communicate between layers in a sub-system.
***[Design Patterns](https://www.educative.io/courses/software-design-patterns-c/conclusion)*** recognizes this potential:
**“Because Subject and Observer aren’t
tightly coupled, they can belong to different layers of abstraction in a system. A lower-level subject
can communicate and inform a higher-level observer, thereby keeping the system’s layering intact”** [(Gamma et al.)](https://www.educative.io/courses/software-design-patterns-c/conclusion).<br>
This property may serve as a tool for minimizing the impact of modifications by following the
stable dependencies principle and yet enable bidirectional communication between layers.
* **Potentially complex management of object lifetimes**: As illustrated above, the **First-Class ADT** pattern simplifies the management by encapsulating the interaction with the subject. However, if the subject is also implemented as a first-class object, the dependencies must be resolved on a higher level. The client has to ensure that the subject exists as long as there are observers attached to it.
* **May complicate a design with cascades of notifications**: If case an observer plays a second role as
the subject for other observers, a notification may result in further updates of these observers leading to
overly complex interactions. Another problem may arise if an observer modifies the subject during its update, resulting in a new cascade of notifications.
* **Lowers the cohesion of the subject**: Besides serving its central purpose (in our example being a
time-source), a subject also takes on the responsibility of managing and notifying observers. By
merging two responsibilities in one module,  we increase the subject's complexity. This extra complexity is acceptable when the loose dependencies gained by introducing the **Observer** pattern provide significant benefits. Further, we can simplify the subject in cases where there isn't any need to detach observers during the subject's life. In such a case, the detach function is simply omitted.

* **Trades type-safety for flexibility**: ``` The gist of the Observer pattern ``` is that the subject should be
able to notify its dependents without making any assumptions about who they are. I.e. it must be
possible to have observers of different types. The solution here uses ``` void* ``` as the common abstraction
of an observer. The potential problem arises as the subject notifies its observers and passes them as
``` void* ``` to the notification functions. When converting a void-pointer back to a pointer of a concrete
observer type, the compiler doesn’t have any way to detect an erroneous conversion. We can prevent this problem by defining a unique notification function for each type of observer in combination with a binding such as the TimeObserver structure introduced above.


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



Consequences of Using the Observer Pattern

In this lesson, we will explain the 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

Consequences of Using the Observer Pattern

Consequences