Should one be strict on design pattern implementation?

Question

I'm currently reading, "Design Patterns:Elements of Reusable Object-Oriented Software" by Erich Gamma and others. I decided to do some small projects to see the actual result of applying design patterns to the software I write.

How strict should I be on implementing them? I have seen some examples on the internet that implement the interpreter pattern which just skip entire classes/interfaces/methods in the implementation. Should one be allowed to do the same or is it better to be strict about the implementation to avoid future problems, i.e. to pre-support functionality? Or are design patterns not to be seen as the answer to everything and should they be applied in a way that applies to the current situation, i.e. code specific?

Answer 1

That is why they are called patterns and not algorithms or interfaces.

They are a generic description of designs that keep cropping up in applications. Each implementation will be specialized for the situation that it is used in though the overall pattern of how it does things will be the same.

Answer 2

For anything you do with design patterns, you should be able to ask yourself one simple question: how does this make my software better? Be specific about it. If you can't list of concrete advantages of implementing a design pattern in your specific situation, don't bother; and likewise, if you get the "gist" of the pattern, you'll likely be able to implement the parts of it that are useful to your situation.

The Design Patterns book is particularly good here - they list specific advantages to using each pattern, and detailed cases where they're appropriate, and why.

Answer 3

As it's been once pointed out at SO, using your brain is the best way to write good software. All depends on the specific situation.

Answer 4

There is no silver bullet. A design pattern is a guideline, a formula for reusable designs that have worked for others in the past for achieving a solution to a common problem. However, if there are parts of that pattern that would unnecessarily complicate your software, it's not entirely necessary that you use it.

A design pattern's goal is to simplify and streamline your design. If it doesn't do that, it's not worth using.

Others may have differing opinions.

Answer 5

In addition to Ian Varley's point of "how does this make my software better?" You can extract the following from that statement: "Does this reduce complexity in my software?" Managing complexity is key when designing software and design patterns should contribute to this.

Answer 6

Should one ... to pre-support functionality?

That depends how soon you'll need that functionality, and on how absolutely certain you are that you will need it at all, but often the answer is "no": Google for the term YAGNI

Well, what I actually meant was that one of the purposes of design patterns is reusability and I could reuse the code in other projects.

My policy and/or the YAGNI policy tends to be:

1. Code what I need now
2. If I need something else later, then reuse and/or change what I wrote previously, perhaps by Refactoring

Both of these steps are quicker and eaier if I didn't implement in the first place, and then don't need to change later, functionality that I don't even have any need for yet.

Answer 7

Just about everyone who reads that book falls prey to "Small Boy With A Pattern" syndrome. You start looking for ways to inject patterns into your code, whether they fit or not. Eventually you calm down and realize that the book is just as much about a common vocabulary for communication as it is about lines of code.

It's a terrific book, a classic. If you look in the Java or C# SDK you'll see that both are rife with examples (e.g., Proxy in Java RMI, Decorator all over the java.io package, Factory in java.sql and JDBC, etc.)

But I find that they work best when they're discovered during the development process rather than force fed to the code base.