Getting rid of the band of four design patterns is nonsense

Someone found Yet Another Post (YAP ™) insisting that the Gang of Four (GOF ™) models were on their last legs. The email was misleading, as that is not precisely what the article said. The bottom line was that Design Patterns in general are just an answer to the shortcomings of the underlying programming language, a position that is absurd at its core.

The lexicon of design patterns varies from language to language. GoF models do not “go away”. They are part of the Java / C ++ world. They don’t apply quite the same to Python or functional languages.

There is, however, a more serious problem: linguistic mapping. First, a bit of context.

Design Templates

Design Patterns will always exist. They are an artifact of the way we treat the world. We tend to categorize individual objects so that we don’t have to treat each object as a separate natural wonder.

It’s just another brick in the wall.

We don’t have to look at every rectangular ceramic solid and understand its beauty. We can group and summarize. To classify. Brick is a design model. Masonry too. The wall too. They are all models. This is how we think.

Design patterns and language gaps

Some argue that the switch to functional languages ​​will kill design patterns. This assumes (in part) that non-OO languages ​​magically don’t have design patterns. It’s (see above) a little crazy. Languages ​​have design patterns. We recognize these patterns all the time.

A functional language has a common technique (or model) for visiting nodes in a hierarchy. We don’t dwell on the beauty of the code like we’ve never seen it before. Instead, we categorize it based on the design pattern and leverage that higher level understanding to understand why we walk in a hierarchy.

The death knell for design patterns also assumes (in part) that functional languages ​​are magically more complete than OO languages. In this new and better language, we don’t need models because there are no gaps. It’s pretty much crazy, too. The Patterns Fill Language Gaps school of thought ignores the fact that there are many ways to implement these “gaps”. We may use GoF design templates, or we may use other software designs that do not match GoF design templates. Both work.

The reasons do not fill a “gap”. They provide advice on how to implement something. That’s all. Nothing more. Advice.

“But wait,” you say, “since I needed to write some code, this is proof that there is a gap. “

“What?” I ask, incredulous. “You claim that all code is proof of a language gap? Does it mean all application software is just a language gap? “

“Let’s not be silly,” you say. “I can cut a hair and make a very small distinction between software that I shouldn’t have to write and software that I should have to write.”

I remain incredulous.

Design patterns as damage

The idea that somehow GoF’s design patterns are a problem is also wacky. The GoF design templates are quite slick. They solve a fairly large set of problems in an elegant and cohesive manner.

They’re just good design.

Yes, they can be complex. Sorry about that. Software can be complex if you want really great flexibility and scalability.

AND.

Premium.

Software can be complex when you need to work around “compiler” and “libraries locked” and “no source” issues. That is, the GoF models fully apply for C ++ and Java where you try to protect your intellectual property by only disclosing obscured headers and implementation details. Indeed, there are few alternatives to GoF models if you are going to distribute a framework that has no visible source and must leave extension points for users.

If you don’t have a Locked-NoSource-Compiled code as a backdrop, GoF templates can be simplified a bit. But some of the models are essential. And remains essential. There are some great ideas out there.

In the Python world, we rely on a modified subset of GoF models. They work extremely well.

When writing functional-style Python using immutable data structures (where possible), we use a different set of design patterns. Not so many GoF models when trying to avoid stateful objects. But some models (like the abstract factory) are really very useful even in a largely functional context. It changes from an abstract factory class to a factory function, and it loses the “abstract” concept that is part of C ++ and Java, but the basic factory design pattern remains.

The serious problem

The serious issue raised by the email is language mapping. We can’t (and shouldn’t) try to map languages ​​to each other. What is true for Java design is absolutely not true for Python design. And this does not apply to assembly languages, FORTRAN, FORTH or COBOL.

The languages ​​are different.

The. I said it.

If there was a “universal deep structure” underlying all programming languages, the surface features would just be syntax, and we would have automated translation between languages. The deep universal structure (the underlying Turing machine that performs the calculations) appears to be too abstract to be well represented among programming languages. Hence the lack of translators.

When changing languages, it is important to leave all luggage behind.

When switching from Java = 8 (i.e. from non-functional Java to more functional Java), we cannot trivially map all design patterns among language features. It is a new language with new features which happens to be compatible with the old language.

Trying to trivially map concepts between non-functional (or strictly OO) Java and more functional Java leads to stupid conclusions. As GoF models are dying. Or the GoF models represent damage or something just as awkward.

Changes in language lead to changes in the design pattern.

The change of language doesn’t deserve a happy / anguished blog post celebrating / lamenting the differences. It is a consequence of learning a new language or new features of an existing language.

Please avoid mapping languages ​​to each other.


Source link

Abdul J. Gaspar

Leave a Reply

Your email address will not be published.