What is the most underused or underrated design pattern?

Question

I've been reading a lot about design patterns lately, and some of them can make our life easier, and some of them seem to just make things worse (at least I like it). I'm curious to know which design patterns everyone considers to be underdeveloped or underrated. Some templates are simple, and many people don’t even realize that they are using a template (the decorator is probably the most commonly used, not implemented). My goal is to give us an opportunity to get an idea of ​​the patterns for some more complex or unknown models and why we should use them.

Answer 1

The most important “patterns” for beginners are

• Keep it simple.
• Find out why good practices may be good, so you can tell if they are good for a particular situation.
• You must balance competing issues for the situation, and not just think about one thing. (denouement v. cohesion, resistance to testing v. completeness, best practice v. time)

Regarding formal templates with cool names , I think an overview of interface-oriented templates will be useful because it helps you think about dependencies and contracts, and not just about objects. Or, as Uncle Bob (Martin) says, depend on abstractions, not nodules. Therefore, I answer:

• Dependency Injection
• (to a lesser extent facade , decorator , adapter )

See Dependency Inversion Principle , one of the SOLID Principals , (which I am sure you have already analyzed). Looked narrowly, DI is very simple , although it has often been made overly complex. I consider it also important to look at it in a broader context, think about each level and part of your design, and not just design a specific code.

A small word of warning. I think that some novice templates become overly zealous with templates and do not think that the code is good if it does not implement the template and that the template makes the solution good. They sometimes focus on templates to the detriment of other good OOP / D methods. This is mistake. Mr. Sol himself explains this here .

Answer 2

Less code is better code.

Answer 3

I am a big fan of testing monte carlo. Many very complex and efficient algorithms are extremely difficult to verify because there are so many different code paths and boundary conditions. If there is a naive algorithm that does the same thing as your complex algorithm, or even one that just makes different trade-offs (like a hash table or a balanced tree), you can simply generate tons of random input data, a naive and efficient algorithm , and make sure the results match. I found many unpleasant errors in edge cases in such a way that otherwise it would be almost impossible to find.

Answer 4

I implemented the Strategic Template the other day, it is used to encapsulate methods, which you can swap at runtime. Like the Command Pattern, but more untied.

This is how I used it. I had to send files to third parties, and I had several choices: I had FTP, SFTP, FTPS and SMB.

Interface:

interface ITransferStrategry { void TransferFiles(System.Collections.Generic.IList<string> files); } 

Implementation:

 public class FTPTransfer : ITransferStrategry { public void TransferFiles(IList<string> files) { // Transfer to FTP Code Here } } 

Context:

 public class TransferContext { private ITransferStrategry _strategy; public TransferContext(ITransferStrategry strategy) { this._strategy = strategy; } public void Send(IList<string> files) { this._strategy.TransferFiles(files); } } 

Client:

 public void Client() { TransferContext context = new TransferContext(new FTPTransfer()); context.Send(files); } 

It is quite easy and simple to maintain. Hope this helps someone.

Answer 5

Common sense and efficiency can replace all design patterns.

EDIT: See that the commentators did not understand my point ...

What I tried to say is that instead of remembering all the design and thinking patterns in these terms, you can just think about the problem for a while and solve it in an effective and elegant way, based on common sense and on your experience, With good in all likelihood, what you come up with will be one or more of those design patterns. But you do not need to know them in advance in order to use them. In any case, I can never master the memorization of the names of these 20+ models and the retention of the mental associations of what each name stood.

Answer 6

Balance

I mean that there are all kinds of patterns and recommendations, but all of them can be excessive, which leads to the effect of anti-pattern.

The experience of what and how to apply well-known methods comes with every line you write, every discussion you have with other coders, and every reading of reviews from people who think is different.

Answer 7

The most unfinished design template is all. As mentioned earlier, many people who use design patterns are not so good about the pros and cons. I also think that “why is so much attention paid to the specifics of the templates? I don’t need to know that the arguments“ names ”cause more and more people, but both of them are much outweighed by people who do not use or think about design at all.

Y-Combinator simply posted this link on the pages of free university lectures on computer science - http://lecturefox.com/computerscience/ - many advanced topics, but not one about OOP or design patterns.

Answer 8

First class functions.