I once saw a guy proving how Lisp eliminated the need for 19 of the original 23 GoF's design patterns from the book called "Design Patterns". 19 of the patterns explained in this book had absolutely no meaning what so ever in Lisp. Lisp was created in 1958. This implies that everything we've done in regards "evolving" software development since 1958 is basically garbage. Design patterns is really nothing but a symptom of a sick programming language, period.
A broomstick is perfect. Even if you've never seen a broomstick before, you would still easily understand how to use it if you saw one. It doesn't require an instruction manual, and it doesn't require taking it out of your closet in a specific "method". Everything that's good in this world share this trait; It's easy to use, self explanatory, and ads no confusion.
Most modern programming languages comes with an "instruction manual" in the form of "design patterns". This is because they are counter intuitive, badly designed, based upon garbage ideas, such as OOP and similar rubbish constructs. In fact, about the only "nice" design pattern I've seen coming out of computing the last 4 decades is IoC. Everything else is basically a crutch for inadequacies found within the language where they are applied.
Imagine if your book needed design patterns to be used. It could resemble something such as follows.
- When opening the book, pray to Bulsebub 3 times, throw some water on your tree if you've got a hedge, for then to say 3 hail Marys. If you don't, the book will burst into flames and become impossible to read.
- If turning the 4th page, make sure you get a haircut first, or page 11 will fall to the ground, and turn into a lizard, ending up eating your grain.
- If you want to store your book in a bookshelf, make sure you create a persistence layer, based upon an
AbstractFactoryAbstractPersistenceFactoryFactoryclass first, or you won't be able to use your left hand later down the road if your right hand is busy holding your beer.
The above is basically how design patterns would look like if they existed in written language and books. Still we accept the absurdity of having design patterns in software development, and we crown ourselves as if we achieved something valuable, if we can only understand them and correctly apply these where needed. Knowledge about design patterns is so important today, that landing a job without reciting the meaning of all characters in "SOLID" has basically become impossible. Preferably with specific use cases, illustrating correct usage. Say after me ...
SOLID is rubbish! It's a symptom of inferior programming languages, incapable of solving things intuitively, period!
I've used Hyperlambda for many years. So far I have not been able to identify more than 2 to 3 design patterns I repeatedly turn to. All other design patterns are basically useless in Hyperlambda. This is because Hyperlambda is a functional programming language. It has no OOP, and none of these garbage ideas all other programming languages are competing to implement as complex as possible.
If you don't know design patterns, relax. There are no reasons to teach yourself these rubbish ideas. They were built for rubbish programming languages, based upon rubbish constructs, resulting in rubbish languages, requiring rubbish design patterns. It's much smarter to just drop the language forcing you to use 500+ design patterns, and focus on simple to use programming languages, where such rubbish design patterns are no longer required. Below is a programming language almost chemically cleansed for design patterns if you need a pointer :)
And you can register a free online cloudlet allowing you to play around with it below.
Design patterns is a symptom of a sick programming language