Should I strictly adhere to the design scheme?

Question

Currently I am reading, "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma and others. I decided to make small projects to see the actual result of applying design patterns for the software that I write.

How strict should I be in their implementation? I have seen several examples on the Internet that implement an interpreter pattern that simply skip entire classes / interfaces / methods in the implementation. Should someone be allowed to do the same, or is it better to be strict with respect to implementation in order to avoid future problems, that is, before functionality is supported? Or shouldn't design patterns be considered the answer to everything, and should they be applied in a way that is applicable to the current situation, that is, to a specific code?

Answer 1

There is no silver bullet. A design pattern is a guide, a formula for reusable designs that used to work for others to solve a common problem. However, if there are parts of this template that would unnecessarily complicate your software, it is not entirely necessary for you to use it.

The purpose of the design pattern is to simplify and simplify the design. If this is not the case, it should not be used.

Others may have different opinions.

Answer 2

This is why they are called templates, not algorithms or interfaces.

They are a general description of the designs that continue to arise in applications. Each implementation will specialize in the situation in which it is used, although the general outline of how it will work will be the same.

Answer 3

What would you do with design templates, you have to ask yourself one simple question: How does my software better? Be specific. If you cannot indicate the specific benefits of introducing a design pattern in your specific situation, do not worry; and similarly, if you get the “essence” of the template, you can probably implement the parts that are useful for your situation.

The Design Patterns book is especially good here - they list the specific benefits of using each pattern and the detailed cases of when they fit and why.

Answer 4

In addition to Ian Varley's “How Does It Make My Software Better?” You can extract the following from this statement: "Does this reduce the complexity of my software?" Complexity management is a key factor in the development of software and design patterns that should facilitate this.

Answer 5

Almost everyone who reads this book becomes a victim of the Little Boy with Sample Syndrome. You begin to look for ways to enter templates into your code, regardless of whether they are suitable or not. In the end, you calm down and realize that the book is as much like a general vocabulary for communication, as a line of code.

This is a terrific book, a classic. If you look in the Java or C # SDK, you will see both options with examples (for example, proxies in Java RMI, Decorator throughout the java.io package, Factory in java.sql and JDBC, etc.)

But I find that they work best when they are discovered during the development process, and not in the root entering the code base.

Answer 6

Should ... support prior support?

It depends on how soon you will need this functionality and how absolutely certain that you need it, but often the answer is “no”: Google for the term YAGNI

What I really had in mind was that one of the goals of design patterns is reuse, and I can reuse the code in other projects.

My policy and / or YAGNI policy tend to be:

• Enter the code I need now
• If I need something even later, reuse and / or change what I wrote earlier, perhaps Refactoring

Both of these steps are faster and more efficient if I did not implement it in the first place, and then do not need to change it later, a functionality that I do not even need.

Answer 7

As already stated in SO, using your brain is the best way to write good software. It all depends on the specific situation.