Choosing patterns

Patterns are not libraries or classes, they're concepts, reusable solutions to common programming problems, tested and optimized for specific use cases. As they're just concepts to solve specific problems, they have to be implemented in every language.

Every pattern has its advantages and disadvantages, and choosing a wrong pattern for a problem can cause you a big headache.

Patterns can speed up the development process because they provide well-tested and well-proven development paradigms. Reusing patterns helps prevent issues and improves code readability between developers that are familiar with the patterns.

Patterns have major importance in high-performance applications. Sometimes, in order to achieve some flexibility, patterns introduce a new level of indirection in the code, which may reduce performance. You should choose when to introduce a pattern or when that introduction will hurt the performance metric you're targeting.

Knowing good patterns is essential for avoiding the opposite: anti-patterns. An anti-pattern is something that looks good in the beginning but later on turns out to look like the worst decision you ever made. Anti-patterns are not specific patterns but are more like common errors, seen by the majority as strategies you shouldn't use. Some of the most common and frequent anti-patterns seen out there are:

  • Repeating yourself: Don't repeat excessive parts of the code. Lean back, look at the big picture and refactor it. Some developers tend to look at this refactoring as a complexity of the application, but it can actually turn your application simpler. If you think you won't be able to understand the simplicity of your refactoring, don't forget to add a couple of introductory comments to the code.
  • Golden hammer or silver bullet: Don't think your favorite language or framework is universally applicable. Most of the languages can actually do practically anything, at least the mature ones, and with a huge community. That doesn't mean a language performs some tasks well. If your goal is performance, try to have a couple of hammers in your belt.
  • Coding by exception: Don't add new code to handle new cases as they appear. By new cases, I don't mean new features; I mean behavior your code was not expecting. For example, when you're making a file upload feature of some kind, remember an error might happen during transfer, the file can be empty, have weird content, be huge, and so on.
  • Programming by accident: Don't program by trial and error until you succeed. This is something you should really avoid. Programming by accident can sometimes make your code work in some cases (by accident) and produce erroneous behaviors in others.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset