The article describes how to deal with Design patterns and practices while developing your application. This article is basically a pointer to all the design patterns associated with the series. Please bookmark this to get links updated for all other articles that are added to the series. Click on a link below to read a pattern.
Software patterns are there and widely followed in the industry for a long time. In Software engineering, a pattern is a generalized solution to a common problem, a software design or an architecture for a given problem. This is the widely used solution to a problem specific to an industry, a person or a goal. A Software pattern can never be identified as a silver bullet to a problem but rather it is widely accepted a solution to a problem. There could be always a notion of adjustment to a pattern to adjust the specific need of the project that is worked on by the developers.
Patterns are essentially formalisms and naming of nice idioms of coding. It is a way to give experience to programmers. It is a nice way to know that both the developers are talking about the same thing while discussing a problem.
Software patterns are first introduced in 1995 by "gang of four": Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. In this book, it is first discussed capabilities and pitfalls of Object oriented programming, and later on, it discusses the classic Design Patterns on OOPS. They introduced the first requirement of a software pattern while developing a piece of software in the industry. Better organizing a code is a lifelong learning experience for every developer and it is hard to follow when some functionality is needed to be implemented by a programmer. A software pattern just gives a sense of guidance to a developer while implementing a code or functionality for a problem.