What seems to be trending heavy in the software industry today is a brain child of the mid 1980’s. Ironically being popular in software development was actually inspired by publication A Pattern Language, which primarily focused on buildings and town planning.

So how did design patterns actually become relevant?

When people got introduced to object oriented programming, they begin to streamline code in the best possible way. While abstracting, there are many ways that code can be re-factored. You wouldn’t want to write the same solution for address different problems. Take something simple, like getting an alert when an email arrives, there could be many ways to write this. Should it alert me before it downloads, or after, or should it alert me when the mailbox file gets updated. More so, one has to design it for reuse.
Design patterns help address specific problems with a specific design. Like hammer is used drive a nail into the wall but a screw could also be hammered into the wall, so while it might work, it’s not the ideal or most efficient tool to use.

Software Design patterns are classified under these categories: Creational; Structural; Behavioral; and to handle multi-threaded: concurrency.

There are many resource on the internet that describe these in more detail, which you can refer to. Some patterns are simple and straight forward and some more complex.

In recent times, there has also been the fact that sometimes you may over-design, you may want your code to be readable but chances are it may never be re-used, at least not in the near future. Sometimes a design pattern could be counter-productive, while it intended to solve a problem, it was either not effective and produced more concerns, these are termed as anti-patterns.

It is good practice to understand the extent of your development and even the type of development, is it a prototype or full blown product that may take years to build into its full capacity.

While MVC you could say is type of design/architectural pattern, it serves only certain solutions, you still need to create answers to business problems in the Model section.

A good way to know if your code needs to be refactored are high complexity, too many lines of code, repeated lines of code with minor parameter differences. If the you think nested if’s, nested loops and needing to code in many layers for small change, you could possible benefit from using a more apt pattern.

In recent times D.R.Y. and S.O.L.I.D. are gaining popularity as well, they a more philosophy to approach your design rather than a focused type of pattern.

Nevertheless, each builds on the other and combination of tested patterns, good programing philosophy and proper bearing on the lifespan of program can bring the most satisfactory approach to more robust code.