About using patterns

Unfortunately, sometimes you have to observe cases when people who have gone through design patterns at an institute as part of a programming course, or have read a book with patterns right after a programming textbook, start using them literally from the first class. Sometimes it gives results, most often with Singleton patterns (at least they know about double locking idiom). But most often a situation arises where a person applies a pattern just to apply it. And that's bad.

For a start, what is a pattern? It can be translated as “sample”, “example”, “model”, but I like the word “pattern” or “design pattern” the most. Because any pattern is not a sample from which to copy your code. This is a sample of the code to follow. The difference is the same as between the sample document that hangs on the wall and the document template in MS Word / OpenOffice Writer, which is used for uniform design (indents, fonts, paragraph formatting).

A little from my own experience. 13 years programming experience. After two years of self-study in books (not a single word about patterns), I wrote several applications “to order”, one of which is still in use. But only two years later, I thought that:

• First, the code must be readable even for itself.
• Secondly, it is quite possible that someone else will have to work with the code.

And then I started asking questions, like:

• How to call a collection of email addresses? MailAccounts?
• Where to put the methods that are responsible for working with postal addresses?
• Where to put the methods that work with the database, so that later it was easy to find them?
• What is the best way to organize access to an object, which in the system should be one and only one? Make public static final (const) field? Make public static method?

Much later, he began to realize that the answer to these questions is precisely what the patterns give. Design patterns not only dictate the rules of naming (then they are not much different from the code design rules), but also determine the structure of the code. Do they determine the way to solve the problem? No, the choice of the way to solve a specific business problem is still left to the programmer. For example, we need to organize access to objects in the database. This can be done in two ways:

• make simple database access using getName (int id), setName (int id) methods
• select an object instance for each row in the database

Or, we need to make a CSV format parser. We can:

• Make a “dumb” parser based on several parseLine, parseToken, parseString () methods, working with sequences of characters
• Make a parser that works with individual characters (onSemicolon (), onDot (), onQuote (), etc)

To solve a business problem, we can choose one of several solutions to the problem. The error of a novice programmer who is familiar with design patterns is that, instead of going through ways to solve a problem, he begins to search for known (and unknown) design patterns to select the appropriate pattern. And, often happens, wrong. In the case of objects in the database, the second method falls under a known pattern, with separate instances of the object for each row in the database. But it won't even occur to the programmer that most of the work can be done using bulk operations, and then you need to use a different pattern. In the case of the parser, the programmer chooses to work with individual characters, since it fits well on the state machine pattern known to him. But as a result, he gets a code that is very difficult to read and impossible to modify. Because he began his choice by choosing a design pattern, and not by choosing how to solve the problem.
')
Even if we consider higher-level templates, such as Model-View-Controller, their use should not be the answer to the stated business problem. The programmer must be clearly aware that in his case, it is really necessary to be able to separate the behavior of the system from the display. And, having come to this idea, presenting how he would do it at least approximately, pay attention to the MVC pattern, which will explain to him exactly what parts to write, how to call them, and what functions to endow.

Knowledge of design patterns help to write code. In the case of simple templates, they help arrange the code to make it more understandable to other people. More complex patterns help to structure the code. But the chain “task” - “solution method” - “template” - “code”, and not “task” - “template” - “code” should be obligatory.

Update: Rewrote the topic, focusing on where the solution to the problem ends and the pattern begins. Not sure whether to republish the topic or need to make a new one. Please do not strongly beat for ignorance of patterns of behavior on Habré