When are design patterns a problem instead of a solution?

Question

Ive never worked on software where I needed to use design patterns. According to Paul Grahams ' article , design patterns are a sign of insufficient abstraction.

To quote it directly: “For example, in the world of OO you understand a lot about“ templates. ”I wonder if these templates are not a random example (c), a human compiler, at work. When I see templates in my programs, I consider this is a sign of a problem. The form of the program should reflect only the problem that it should solve. Any other pattern in the code is a sign, at least for me, that I use abstractions that are not powerful enough - often that I manually generate extensions of some kind the macro I need to write " .

I'm just wondering if everyone thought that the design patterns are over-used and are symptoms of insufficient abstraction in your code.

Answer 1

I don’t think that templates themselves are a problem, but rather the fact that developers can study the templates and then redefine them or apply them as they are inappropriate.

Using templates is something that experienced programmers just learn naturally. You have solved problem X many times, you know which approach works, you use this approach because your skills and experience tell you about it. This is a sample, and everything is in order.

But it is also possible for a programmer who is less able to find one way to do something and try to surpass every problem they encounter in this form because they don’t know the other way. This is also a template, and it is evil.

Answer 2

Please come read the whole quote, read it carefully. Or better yet, read the essay.

Paul Graham criticizes, among other things, C-like languages ​​for not providing adequate means of abstraction. As part of the essay, his criticism of the patterns is an afterthought, or rather, an argument in favor of his main argument. His reasoning is as follows:

It is logical to use common strategies to solve recurring problems. In truly abstract languages, these strategies can be formalized and placed in a library. Whenever you need to use them, you simply # include them, instantiate, expand them, or something else. C-like languages, in contrast, do not provide the necessary means of abstraction. This is evidenced by the fact that there is something like "patterns." A template is such a general strategy that cannot be expressed by library code and therefore must be expressively written every time it is applied.

Paul Graham does not believe that the patterns themselves are evil. They are a symptom of languages ​​that do not provide means for abstraction. In this regard, he is almost certainly right. Should we use different languages ​​because of this, this, of course, is another discussion.

The original question poster, on the other hand, is incorrect: patterns are not “symptoms of a lack of abstraction in your code,” but are symptoms of an insufficient number of abstractions in your language.

Answer 3

Templates are just a way of describing how everything works. This is a way to classify them. Are there any programs that use them? Sure. The biggest advantage of having templates is that when classifying something like this or that, each is on the same page (provided that they have a level of knowledge to know what they are talking about.). When you have a system with 10,000 lines of code, it becomes necessary to quickly determine how something will work.

Does this mean that you should always use templates, no. This will lead to problems in order to get things to be classified, but you also should not shy away from them.

Answer 4

My problem with templates is that it seems that the central lie lies at the heart of the concept: the idea that if you can somehow classify experts by code, write, then anyone can write expert code just by recognizing and mechanically By applying categories, this is great for managers, as experienced software developers are relatively rare.

The problem is that this is not true. You cannot write expert-quality code only with “design patterns” than you can create your own professional clothing for the designer using only sewing patterns .

Answer 5

The form of the program should reflect only the problem that it must solve.

And what happens when requirements change and your module has not been abstracted using Facade or potentially a proxy, which makes it overly difficult to replace?

design patterns are a sign of not enough abstraction

Most likely, if you completely separated everything, then you have a design template somewhere there.

What if there is an extremely “heavy” object that does not need to be loaded? The proxy template keeps the user pending.

I could go on, but I think I have said enough. Design samples are great tools when used properly. The problem arises when they are used improperly, but I think that why incorrectly used patterns are called anti-patterns.

Answer 6

I believe this part of the quote from Paul Graham is important:

[...] I use abstractions that are not efficient enough - often I manually generate extensions of some macro that I need to write [...]

This shows that if you can create these abstractions in your own language (and you can do almost anything with Lisp, which he probably has in mind above), you do not need to model them using patterns.

But not everyone uses Lisp, so you can only create abstractions where you can, and use templates where you cannot. For example, in languages ​​without higher-order functions, they are often modeled using a strategy template .

It seems that the point is how you look at it: a template can be considered as a symptom of a problem (for example, the absence of functions of a higher order) or as a solution to a problem (for example, to do something like functions of a higher order are possible through a strategy template).

Answer 7

[sigh] How many persuasions against good practices do we need to debunk before people use their own opinions?

The short answer is: if you are doing the real job in an object-oriented language, there is a very high chance that you have implemented some GoF design patterns to do the job. Do you know that you did it or not, it is a matter of education, perspective and introspection. To deny that you have ever done this or that template, do not exist or are not “necessary” or “abused”, it is ridiculous - if you never write anything more complicated than “hello world”; -)

Why, just the other day, I had to implement a visitor facade for a singleton to make the adapter strategy work: -P

Answer 8

The term Design Designs is overloaded and confused.

There is a narrow way to think about it: mainly as a collective name for the concepts of TOE listed in the GoF book, for example, Singleton, Facade, Strategy. You probably use this definition if you put design patterns as a competency on your resume.

One project can contain dozens of singleton objects. Obviously, this template is advantageous in that it is encoded as an abstract abstraction, for example, as a macro or abstract class. Similarly for many other patterns in the GoF book.

It seems to me that Paul Graham's thesis is this: design patterns, which are standard ways of repeating yourself, should be codified as realistic abstractions, and as a result you should use a language that has a very flexible way of defining realistic abstraction.

But the concept is more general - I think it distorts design patterns. Christopher Alexander invented this concept to apply it to the design of countries, cities, cities and houses. Game developers have languages ​​such as Fog-of-War, Asymmetrical-Abilities, etc.

In this general sense, it becomes much less obvious that design patterns should be encoded as abstract abstractions.

If you have not read A Pattern Language, view the scope here . Imagine something like this for the software world. GoF samples will be at the bottom of the bottom of the ToC: these are implementation details.

What other patterns could you find above them?

I think that in one chapter there would be templates related to the game. It can include both game design templates and implementation methods - and I argue that this is not a clear distinction, such as Game Loop, World Entity, spatial hash, map height landscape, etc. These are all design patterns.

Now, as part of a single game project, you are likely to have only one World Entity implementation. Anyone who works in any language would make sense to make this World Entity object a realistic abstraction, like a base class.

But what the template describes is how this abstraction is formed: it contains some idea of ​​the position, is visualized, etc. It is unclear whether this design pattern will benefit from coding as a macro or an abstract class in itself - the pattern already describes an abstraction! Would you make a metaclass for realizing the entities of the world? A macro to define classes of world entities with all kinds of unholy parameters?

Looking further at the imaginary content, we see that these patterns are subject to a more general scheme - the game. Is it worth it to code as a macro or an abstract class? May be. But not obvious. We are talking about a gaming infrastructure where you define a computer game by passing parameters, filling in the blanks, etc. It can be productive and fun, but it is not the only way to do something.

Erlang platform has realistic abstractions for templates, as general as a server, which is great. And I assume that the Erlang project has as many servers as the Java project has Singletons.

But for your specific purposes, if you work in Lisp or Haskell or something else and write a server, sometimes it’s enough to just follow the Server template, implementing it as good old functions and objects, without trying to make a real abstraction of all this.

All design patterns are not low-level text patterns in the source code.

Answer 9

I think that Paul Graham does not have a significant time on this. Using templates is not about putting together a book listing them and applying some of them to your code. I would agree that this would be a bad choice, but that’s not what it is about.

Design patterns are just a way of recognizing “Hey, I understand that this looks like another problem I solved before” and learning how to create a good abstraction of the solution so that it is applicable in appropriate situations.

In fact, the likelihood that if you programmed something of a reasonable size, you used well-known design patterns and simply did not know that there was a name for it. For example, I used the "factory" pattern for a long time before I realized that it was a "factory". Knowing what he officially called simply prevents me from reinventing the wheel.

Of course, some well-known templates are a little crappy; Singleton is definitely suspected. But it was a clear example of an overly smart solution looking for a problem to solve, and didn’t do it very well. But why can you find a lot of literature both for and against it, because people learn that this may not be a good solution.

But patterns in general are a very good thing if something encourages abstraction.

Answer 10

I believe that Paul Graham’s statement is that design patterns should be expressed in a language. If there is an X pattern, this means that people are forced to rewrite code sequences to do this, and there must be a language capable of expressing it. This can be built into the language (although it is inconvenient and can create new design patterns), or it can be automated within the language (for example, Common Lisp macros; C ++ patterns, especially when used in strange ways, can do much the same the most sometimes).

For example, consider a much simpler pattern: an incremental loop. The need to do something on each element in the sequence is quite common, and if we didn’t have something that matched the for statement, we would no doubt have adopted some general coding convention to express this, and someone (or someone else) will pack this together with other similarly elementary constructions and write a book about it.

Similarly, if you use the Factory template, either the language can include the Factory function, or it can be automated within the language. In particular, Paul wants to be able to write the Lisp macro to implement it, and not write the plants themselves again and again.

The danger of using a design pattern is that we are familiar with the code structure that we continue to print, and therefore we have pieces of code that we usually don’t read or write with full attention. The inconvenience is that they are code that we have to enter over and over again, and the feeling that rewriting really needs to be automated.

Whether templates are an integral part of using languages, for example, says GoF, or can they be distracted, as PG says, is basically an empirical question, probably best solved by searching for languages ​​where the templates themselves are not needed and observed, see if they really need new templates.

Answer 11

Design patterns are defined as follows (from Wikipedia, but I read the same in some books)

In software development, the pattern is a common reusable solution to a common problem in software development. The design scheme is not a complete design that can be converted directly to code. This is a description or template for solving a problem that can be used in many different situations.

If you look at the application of patterns directly from the offset, without falling into the problem area, this can lead to problems. Use design patterns as a guide or more, as a hint / hint to solve a problem. A heavily applied design template will certainly not provide a sufficiently abstract solution. It is often seen that Enterprise software uses a variant or combination of several design patterns ... hybrids. If you say you never used design templates, you would be happy to know that something like a foreach loop is actually an interaction template, and you can hunt for more obvious implementations near you!

Answer 12

In a nutshell, templates are simply formalized ways to solve common problems in different languages. Thus, there were “design patterns” even before someone coined the term. There are “best practices” for each language, and design patterns are actually a set of best practices for problems that arise on a regular basis.

One of the main advantages of template labeling is that general terminology allows us to talk about abstract concepts.

Obviously, design patterns may be misused or overused in any particular context, but I really don't understand how design patterns as concepts can be a problem.

Answer 13

When I programmed in LISP, I did not use GoF design templates at all, it just is not applicable for the programs that I wrote. Now I program in C # and do all the situations where the design pattern actually simplifies the written program.

Answer 14

There is time and place for everything. I saw code with too many templates, which is consistent with your point, but also with an insufficient number of templates, which makes it difficult to work with the code and prone to errors when making changes.

A generalization of something like this would be logically erroneous, but if you rephrase your question to something like “can there be too many templates in the code, which is a symptom of a more serious problem, that is, insufficient levels of abstraction” then the answer would be “yes” . It's always like that? No.

Answer 15

There are many maxims that we use (and which are common to SO) that, if you trace them to the source, were originally approved with redundancy; as in "... when you develop usage ..." This is one such case. Samples work well when you do OOP. YMMV when you are in a different paradigm.

Refactoring is another similar case.

When I write SQL, part of my "template" is disabled.

Pay attention to your quote: "I manually create extensions of some macro that I need to write." Therefore, it recognizes patterns and abstracts them into a macro - it does not re-encode it differently. Just pretty. These are not patterns; they cannot do the right thing with the ones we find. I would say that his comment can be included in any wiki entry expanding on the merits of DRY and how to own it. GoF totally agrees - it recognizes desgin patterns, and then use what you know about them to implement (or reorganize) them accordingly.

Answer 16

In the design phase of my programs, I often break up the problem first , and as soon as I break it down, I can easily begin to recognize patterns inherent in the design. At this point, I can start applying the well-known design patterns, so when the time comes for communication or design implementation, I have a common language that I can use for communication, and I hope I can reuse some common objects that were previously implemented when implementing a similar template.

Often, when design patterns are applied incorrectly, this is because the process is in the reverse order. Programmer Joe (my apologies to those you named Joe) reads a book about design patterns and says, "OK, I understand Design Pattern X, now how can I apply it to my application?" It is not right.

Design patterns can be powerful weapons, but like everything else, they should be used appropriately, and the programmer should always be ready to incorporate some original thoughts into his design.

Answer 17

I think that sometimes when you study a pattern, you do not just study a pattern. But you gain a new understanding of a problem area that did not exist before. And perhaps this is exactly what you wanted.

Without context for the “problem,” we cannot say whether design patterns are a solution or not.

Answer 18

You never need to use design templates - you can always write code that ignores everything that was known about coding, so far - it may even work. But design patterns can make things easier by providing you with a common language for discussing design.

Diesign templates do not represent too little abstraction - they try to increase the level of abstraction. You can say that "this bit is a visitor", and not "here is some kind of code that recursively traverses the tree of objects, performing operations on them."

Answer 19

Templates are a problem if they are not a solution. By this I mean: if a template is introduced for a template, and not for solving a real, existing design problem in an application, it can cause problems, rather than solve or prevent them.
I constantly tell people at work that the book “The Gang of Four” (“Design Templates: Elements of Reusable Object-Oriented Software”) is a guide, not a guide for good design.

Answer 20

Yes, pg is right there. If you see similar code throughout the application, it means that you are missing an abstraction of this code. Less code is better.

Here's another related article: http://blog.plover.com/prog/design-patterns.html

Answer 21

I would rather work with too many templates than at all. However, the right balance, of course, is the goal.

Answer 22

This sentence does not make sense: design patterns are a sign of insufficient abstraction. Because design patterns are abstraction! Following the answers, I agree that programming languages ​​should be able to express design patterns. However, this is not possible for any situation.

Answer 23

I recall an interview with one of GoF, where someone asked about a common claim that design patterns are tools to replace features that are not in the language. The author argued that A) there are design patterns (not the same ones) in any language, since design patterns are tools designed to work with language idiosynchronous languages, and B) it is impractical to get rid of their needs by adding more functions to the language.

Answer 24

Design patterns are solutions to common problems.

But first you need to know what and where is the problem. And that moment when people cannot use templates correctly.

Answer 25

I have not yet found a use for GoF "Design Patterns" in my code. Koderati seems to be trapped in the GoF book, and it is now expected that in most companies you know and apply them. Only today I had an interview and was asked which templates I knew and used, and how I would apply them to a corporate application for a large bank.

The general idea of ​​learning from our previous projects obviously makes sense. What does not make sense is the hype and cult around specific GoF templates, people who take them for good coding, and are expected to love and hug them to be called a competent developer.

So, to answer your question, I would say that the idea of ​​GoF design design is misunderstood and overused by most. We need to focus on the higher-level use of design patterns as a general learning tool that applies to the way we learn and improve OO - not just as 20 cookie cutter ideas for remembering and overlaying on programs. There is no silver bullet.

Answer 26

Programming languages, such as spoken, provide you with a dictionary to speak whatever you want. Templates describe only a way to say things that let people know what you are talking about at a higher level.

If you betray me in a metaphor: Writing music is a common “problem”, and music often (obviously not always) loosens up as some kind of variation on the following:

couplet choir verse choir verse choir choir

Which, indeed, is a "model". You still need to write a song, although not every song written will work well using this template.

What I'm trying to understand is that templates are not a ready-made solution for programming or music. They are a guide for you to start and a springboard from which you can make something that suits you.