---

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. 

Introduction

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. 

Software Patterns are generally categorised into

1. Design Patterns
2. Enterprise Architectural Patterns
3. Software Principles

Design Patterns

• Creational Patterns
  • Singleton Patterns
  • Factory Patterns
  • Factory Method
  • Abstract Factory Patterns
  • Builder Patterns
  • Prototype Patterns
• Structural Patterns
  • Behavorial Patterns
  • Bridge Patterns
  • Decorator Patterns
  • Composite Patterns
  • Flyweight Patterns
  • Memento Pattern
• Behavorial Patterns
  • Mediator Patterns
  • Observer Patterns
  • Iterator Patterns
  • Visitor Patterns
  • Null Object Patterns
  • Chain of Responsibility Patterns
  • Command Patterns
  • Interpreter Pattern

Enterprise Architectural Patterns

Software Principles

• Single Responsibility Principle
• Open Close Principle
• Liskov's Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
• Package Cohesion Principles
• Package Coupling Principles

Conclusion

Patterns are the widely accepted solution to problems. It is important to at least know the patterns of creating some kind of architecture that suits your needs. There is always an element of improvement in this industry. Let's hope as this wiki grows and we can add more and more content to it. There would be much more talks in the betterment of the software industry.

---