Interesting programming patterns
Do you know the diamond problem? Well, everybody knows it and it is boring and old. This post is about not-so know patterns (at least that’s what I think). The patterns show in this post affect the language design. Maybe in a future post I’ll try to aggregate patterns that affect library/application design only.
Be warned that not all “solutions” shown here are implemented in stable versions of the mentioned languages.
Open Type Switch
You can make a switch statement based on the value in several programming languages. Some are more restrict and only allow you to use integer values. But what about type-based switch? Not every one is happy with the visitor pattern.
You were taught about how you could override a method/function-member in a inherited class to provide specialized behaviour. But the dispatch is based solely on the this/self argument. What about multiple dispatch?
Imagine a class inheriting from Matrix to provide faster operations to that kind of Matrix. If you invoke the following code, it’ll be faster:
But what about the following one?
This is exactly the problem that multiple dispatch try to avoid.
Generators (and the yield keyword)
This is an interesting technique that reminds me of the producer/consumer pattern.
Think about the fibonacci numbers as a producer. And about the sum-of-all-elements as a consumer. Without the concept of generators, you could create a function that returns the list of n elements of the fibonacci sequence. Then you could create a consumer to sum all elements.
This approach is too problematic. The most notable problem for the client might be the performance. The programmer may notice that this approach cannot handle infinite (not flexible). We could use functional programming to improve the solution.
We could use a special number (like -1) to handle the infinite-case, but this solution suffer from other problems. For instance, there is an inversion of control (you cannot stop the work of the producer function inside of the body of the consumer function). And also, you now must know the argument n before calling the consumer. So, here we have generators (and an yield keywork to make everything easier) to solve this problem:
A generator is an example of the coroutine concept. This concept is about a function that has multiple entry points (it can resume later) and it is used in a few patterns (asynchronous programming, for example).
Asynchronous programming with async and await
Are you tired of coroutines already? Because there is more! The async/await keywords from C#. I didn’t find a before-after text in the C#’s site, then I’ll grab a simple example with C++ code.
Here is before async/await:
And here is after async/await:
This await keyword could make the life of node.js developers quite easier.
Here is the C#’s (and no, I do not like to program in non-portable languages) site about this feature:
Single-dispatch generic functions
In some statically-typed languages, you have the power to create functions that have the same name, but receive different argument types. This is called function overloading and you may be aware of that. But for several dynamically typed languages, it doesn’t make sense to create two functions with the same name, because the language is dinamically typed and you can call any function with values of whatever type you want.
If you want to create a function that can handle different types, you have invent your own dispatching code or implement all logic in the same function. Too problematic.
You should see what Python developers proposed:
Did you like this post? Why not spent 5 minutes writing about the patterns that you think that are interesting? Post a link back here, then we can be aware of your text (and my programming knowledge will increase).