Showing posts with label java design pattern. Show all posts
Showing posts with label java design pattern. Show all posts

Friday, April 29, 2011

Chapter 52: Design Pattern Elements

Before we dig into the specifics of the Design Patterns that are part of the SCWCD Exam, we need to know one important thing. “The Elements of a Design Pattern”. This is what you are going to learn in this chapter.

So, lets get started!!!

Elements of a Design Pattern:

There are many ways to define a pattern, but the classical way is to describe its elements, or the aspects of a pattern.

The 3 main elements in any Design pattern are:
• Context
• Problem and
• Solution

The following are their definitions:
• Context is the recurring situation in which a problem to be solved is found.
• Problems are the so-called forces, such as marketing and technological forces, that occur in this context.
• Solution is the defined design that reorganizes or manipulates, some say resolves, the problem forces into a desired outcome within that context.
The design pattern is not only these three, but the relationship between the three and the formal language that describes the whole business.

For the sake of easy understanding & explanation, the following are the elements that would be used while explaining each of the design patterns that are covered in this series:
• Is — A direct explanation of what the pattern is.
• Is Not — An attempt at contrasting the concept because it is often helpful to understand what something is by looking at what it isn't.
• Analogy — This provides a comparison based on general aspects. Analogies, hopefully, give you a way to connect what you already know to these patterns which may be new to you.
• Problem — A statement of the problem that describes the patterns reason/purpose and intent.
• Responsibility — This describes what the pattern is accountable for; the primary things it accomplishes.
• Aim — These are the goals and objectives the pattern should reach within the given context.
• Primary Activity — What the main activities done by the pattern are.
• Context — The conditions and environment in which the problem and its solution recur. In other words, where should you consider and apply this pattern?
• Benefits — Why use a particular pattern, its benefits or advantages.
• Usage — Which kinds of situations are good candidates for this pattern.
• Consequences — This describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It may solve one problem, but give rise to a new one.
• Uses — This tells you one or more examples of how this pattern is being used.
• Other Related Patterns — This names other patterns that are related by context, solution, or consequences. The related pattern may solve the same problem in another way or share the same context, but resolve different forces.

Patterns on the Exam

From the SCWCD Exam perspective, you need to worry about only 5 patters and we will be covering all of them, one by one. As a precursor, the 5 patters are:
1. Value Object
2. Data Access Object
3. Business Delegate
4. Front Controller &
5. Model View Controller (MVC)

Exam Trivia:
If you see any other pattern name, ignore it unless the question is one of those about which one is not a pattern.

Previous Chapter: Chapter 51 - Introduction to Design Patterns

Next chapter: Chapter 53 - Value Object Pattern

Chapter 51: Introduction to Design Patterns

Design Patterns are a very important topic from the SCWCD Exam perspective as well as from being a J2EE Programmer perspective. Any experienced J2EE programmer is expected to know about a few of the J2EE Design Patterns. These patterns are used extensively and are very useful to create enterprise class J2EE Web Applications. In this next few chapters, we are going to look in detail, some of the most commonly used Design Patters (Of Course, only the ones that are part of the SCWCD Exam)

This chapter, is going to be a short and sweet introduction to the J2EE Design Patterns.

So, lets get started!!!

A word of Caution: This chapter assumes you've read the previous chapters (well, obviously) and that you are familiar with object-oriented programming concepts, including the popular UML diagramming notation.

History of Design Patterns

The term “pattern” comes from the architect Christopher Alexander who wrote several books on Construction and Building. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas. Alexander, a building architect, was the first to “codify” patterns for architecture. Alexander didn't invent the idea of patterns nor was he the first to see them in designs. Of course, they were there before him, but his work on urban planning and building architecture isolated the idea better than anyone before him. Alexander was an architect extraordinaire. He is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name Pattern Language and defined it at length in his seminal book by the same name.

While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the Gang of Four (GoF as we will refer to them henceforth), as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are now known, applied his patterns to software in their classic Design Patterns: Elements of Reusable Object-Oriented Software (1995, Addison-Wesley). It took a while, but the GoF have started a ground swell. There are now dozens of books, and numerous websites in the internet, about design patterns.

What is a Design Pattern?

Design patterns are often defined as “a solution to a problem in a context.” This falls short of the abstract definition that experts prefer.

Sun defines them in the following way: “A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”

Design Patterns are everywhere and are used (knowingly or unknowingly) by almost all J2EE Developers. Don’t worry my friend, you will be using them too and by the time you are done reading the next few chapters, you will be a Design Pattern Expert.

Previous Chapter: Self Test - Chapters 47 to 50

Next Chapter: Chapter 52 - Design Pattern Elements
© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

ShareThis

Google+ Followers

Followers