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

Observer let us decouple the sender and receiver of an event notification.

Observer is a more general implementation of Strategy.

Observer provides a powerful way of inspecting the runtime behavior of a First-Class ADT.

Observer refers to the general concept of pair-programming.

The open-closed principle is a tool for managing dependencies between different parts of our code, and we have seen how the Strategy patterns lets us achieve loosely coupled designs along that principle. The Observer pattern is another dependency management pattern that also supports the open-closed principle. More specifically:

The open-closed principle is a tool for managing dependencies between different parts of our code, and we have seen how the Strategy patterns lets us achieve loosely coupled designs along that principle. The Observer pattern is another dependency management pattern that also supports the open-closed principle. More specifically:

Software entities should depend on the direction of stability. 

Once we have a dependency, we should never change it since our design diagrams will get outdated.

It's not so much a principle as a cynical observation: once we introduce a dependency in our design, it's hard to get rid of that dependency.

What is the core idea of the Stable Dependencies Principle?

What is the core idea of the Stable Dependencies Principle?

Yes, and it's a powerful way of avoiding special cases; a subject might not have any observers registered, and it's a perfectly valid case. For example, consider program initialization where the observers might get registered after the subject is already running. 

No, there has to be at least one observer to trigger the subject.



The text claims that an Observer has a one-to-many dependency. Could that dependency be one-to-zero?

The text claims that an Observer has a one-to-many dependency. Could that dependency be one-to-zero?

A ```void*``` pointer lets us print the name of the original type to our console during debugging.

Since ```void``` means empty, a pointer of that type never consumes any memory. This represents huge savings in terms of RAM.

We can convert any pointer to ```void*``` and back to its original type again without losing any information.

The one-to-many mechanism where a subject can notify multiple observers leads to an interesting implementation challenge: each specific observer can be of a different type. We solved this using ```void*``` pointers. What's the property of the ```void*``` type?

The one-to-many mechanism where a subject can notify multiple observers leads to an interesting implementation challenge: each specific observer can be of a different type. We solved this using <code>void*</code> pointers. What’s the property of the <code>void*</code> type?

The main benefit is information hiding. Any implementation details – such as using the Observer pattern to register/deregister notifications – are encapsulated in the ADT creation and destruction API.

The First-Class ADT is a  prerequisite for being able to convert types of a `void*` pointer.

A First-Class ADT lets us decouple the subject from the observers by providing an extra level of indirection in our design.



Throughout the patterns, we have seen that the First-Class ADT pattern offers several benefits as the foundation when implementing more complex patterns. What is the main benefit of implementing the Observer pattern as a First-Class ADT?

Throughout the patterns, we have seen that the First-Class ADT pattern offers several benefits as the foundation when implementing more complex patterns. What is the main benefit of implementing the Observer pattern as a First-Class ADT?

Observer gives the subject one extra responsibility that isn't part of the core domain. That is, the subject gets a lower cohesion.

The management of notifications can become complex if observers are temporary and unregistered during a notification chain.

The introduction of a void-pointer means that the compiler doesn’t have any way to detect an erroneous conversion.

When studying patterns, it's just as important to be aware of the negative trade-offs as the benefits. Which of the following trade-offs are true for Observer implementations?

When studying patterns, it’s just as important to be aware of the negative trade-offs as the benefits. Which of the following trade-offs are true for Observer implementations?

Test your knowledge of the observer 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 Observer Pattern