Must have:
- Design Patterns
Early in 2023 an extremely influential academic died.
Generally speaking, academics are only extremely influential within their primary knowledge domain: this one however, was influential within his knowledge domain, and then again within ours. Christopher Alexander was his name: born in Vienna, Austria, educated (though not exclusively) at Harvard, USA, he lectured and held a professorship at the University of California, Berkeley, USA and died aged 85 in Binsted, UK.
If you ask a software engineer whether they know of his name, I am pretty certain that you will get a varied response.
The work of Alexander et al. had a direct influence upon the thinking of some well known names within our field of expertise: Do you know the names Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (also, sadly, no longer with us)? Of course you do. Everyone in software engineering knows these names, right? Collectively they came to be known as The Gang of Four after their seminal work, Design Patterns: Elements of Reusable Object-Oriented Software, was published in 1994.
The patterns presented in Design Patterns: Elements of Reusable Object-Oriented Software are usually what is being referred to when you see that job listing stating that a "...knowledge of design patterns" is required, though on occasion this also encompases the patterns presented by Martin Fowler within his publication Patterns of Enterprise Application Architecture
As previously mentioned, many job specifications list design patterns as a pre-requisite; but what does that mean exactly?
For example: many (and I mean many) software engineers/developers use these patterns every day without knowing who the Gang of Four are, or without knowing what an Abstract Factory is, or where one would use an Adapter, a Decorator, or the Bridge pattern; many would struggle to differentiate between a Behavioural Pattern, and a Structural Pattern, or a Creational Pattern: but they use these patterns every day.
Then there is the converse, where an individual knows the names of those patterns, and understands how to implement them, and yet might still use or suggest them as the wrong solution.
Knowing what a tool is does not ipso facto directly translate to understanding how to use it, or how to manufacture it. This is where understanding comes in to play. I posit that it is extremely important to understand design patterns, to fully appreciate what each "pattern" is, and what problems it solves, because that is the heart of the matter: what problem is this pattern a solution for? When the individual has gained this understanding she will see these patterns all around her, and she will see where they are applied correctly, or incorrectly, she will see where they are the missing solution and she will see where they are overkill (when implemented in full). A pattern is only a pattern because it is a known solution to a known problem.
Controversially, I am going to say no, you do not necessarily need to know how to implement all of the documented design patterns which currently reside within the public domain, especially so when using modern programming tools, languages, and Frameworks: for example .Net 7.0
Knowing how to implement many of those documented design patterns is nowhere near as essential today as it was in 1994, and some might even argue that knowing where to apply them is nowehere near as essential today as it was in 1994 -which is not, however, a view held by this author.
So why, I hear you ask, is knowing how to implement these patterns not as important today as it was in 1994? And in answer to that, I present to you, the contents of this repository.
Jump right in to the code or take a bit of time to read the accompanying documents that I have painstakingly taken the time to put together by way of describing what is laid out within this C# solution.
-
This project will run all example projects sequentially
-
Just to satisfy curiosity, I have put together a means of obtaining some Benchmarks detailing both speed and Heap allocated memory.
-
This project demonstrates how a devloper/engineer can unwittingly make use of several design patterns whilst being blissfully unaware.