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

Design patterns refer to the limited and highly exclusive set captured in the book ***Design Patterns: Elements of Reusable Object-Oriented Software*** (Gamma et al., 1994). 

An idiom is a language-specific pattern that depends upon the idiosyncrasies of the implementation technology. As such, an idiom is typically less relevant in another programming language. 

An idiom is an idea that hasn't evolved into a design pattern yet.

What's the difference between a design pattern and an idiom?

What’s the difference between a design pattern and an idiom?

`sizeof` is an operator evaluated at compile time. That means the compiler does the heavy lifting to provide the correct size.

To `malloc`, it doesn't matter if we're dereferencing an invalid pointer as long as the object size is correct.

It sure looks dangerous; let's duplicate the type information on the right hand side too: `HelloTelegram* telegram = malloc(sizeof(HelloTelegram));`

The idiom **Sizeof to Variables** helps ensure that the size information automatically matches the type provided as another argument to an API. A classic example is `malloc`, where we can guarantee correct allocation using the following form: `HelloTelegram* telegram = malloc(sizeof *telegram);`. What's the reason that this works? That is, why isn't the `*telegram` construct dereferencing an invalid pointer?

The idiom Sizeof to Variables helps ensure that the size information automatically matches the type provided as another argument to an API. A classic example is <code>malloc</code>, where we can guarantee correct allocation using the following form: <code>HelloTelegram* telegram = malloc(sizeof *telegram);</code>. What’s the reason that this works? That is, why isn’t the <code>*telegram</code> construct dereferencing an invalid pointer?

There haven’t been many good ideas coming out of Python thus far. This idea will likely be no different.

We can use **Named Parameters** as a bandaid. If a function call becomes complex, consider refactoring the code instead. E.g., introducing a struct to encapsulate related arguments, split the function to make it more cohesive.

**Named Parameters** come with a high run-time cost as there will be several CPU cycles spent just trying to match values to parameter names.


The idiom **Named Parameters** takes inspiration from other languages like Python where we can make function calls more expressive by clarifying the purpose of each parameter. Yet, the author seems reluctant to use it except as a last resort when calling an API we don't control. Why?

The idiom Named Parameters takes inspiration from other languages like Python where we can make function calls more expressive by clarifying the purpose of each parameter. Yet, the author seems reluctant to use it except as a last resort when calling an API we don’t control. Why?

Assert is unpredictable at run-time and can add a significant memory overhead that impacts our clients.

Asserts return value is always a string, and hence we cannot convert it to a Boolean value that we need to distinguish the happy day path from an error scenario.


Assert is a macro intended for debugging purposes, and compiling the code with ```NDEBUG``` defined removes all assertions.

The idiom **Assertion Context** simplifies debugging by acting as an executable comment. What's the main reason that we cannot replace error handling with assert statements?

The idiom Assertion Context simplifies debugging by acting as an executable comment. What’s the main reason that we cannot replace error handling with assert statements?

Test your knowledge of the idiomatic expressions concepts with this quiz.



Quiz: Idiomatic Expressions

Test your knowledge of the idiomatic expressions 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: Idiomatic Expressions