Design Patterns & Anti Patterns

Architecture and Patterns are the terms borrowed from Civil Engineering. Christopher Alexander, a great Civil Architect, had documented more than 250 patterns in his book ‘Pattern Language – (1977)’ related to Civil Engineering (online copy of the book is available here: http://downlode.org/Etext/Patterns/). As inspired by the pattern language, software engineering has formulated its own patterns for software system development.

Design Pattern - What does it really mean?

In simple terms, ‘it’s a proven solution’. A pattern is composed of problem statement and solution details. It should be technology or language neutral.

Why should one use it?

‘Pattern’ is something that is commonly documented. When you use something that’s common for all, people can easily understand it. Pattern will help you when you code/implement complex designs.

Are the Design Patterns specific to Object-Oriented system?

Need not to be. Design Patterns are heavily used in context of Object Oriented design. All the examples and tutorial we find on books and Internet talk about Design Pattern in OO.

For structural specific design problem one can go for Recipes.

What is Recipe?

Recipe is a documented, sequential set of instructions for a recurring, specific, design issue in Structural language like Assembly, C and etc.

How many Design Patterns are there?

They are countless. As people come up with a new pattern every now and then, it is very difficult to document them. However, a Gang Of Four has documented 23 patterns, and they are the most common, and popular patterns in OO design. You can refer the following book ‘Design Patterns - Elements of Reusable Object Oriented Software’ for details.

As this age is for frameworks, we can find lots of patterns that are specific to frameworks.

What are all the patterns specific to J2EE Framework?

There are so many. There are patterns for each and every tier. I personally recommend to start from here: http://java.sun.com/blueprints/corej2eepatterns/Patterns/. Sun has well documented the core design patterns for J2EE.

Is it mandatory to use patterns? Some of the design problems not covered by any patterns, what to do in this case?

Choice is yours. More you use the patterns, more you generalize your design or implementation. Coming to the second question, design problems are specific in most of the cases. So, there cannot be a pattern for every design problem you face. Suppose, if you find the scenario is recurring frequently, and not yet documented, you can document it as a new pattern. Most of the time, it will be a mixture of existing patterns.