My under eye areas maybe dark but my future will be bright and that is more important.
--Your friends at LectureNotes

Note for DESIGN PATTERN - dp by akhil krishna

  • Note
  • G pullareddy engineering college - gprec
  • Computer Science Engineering
  • B.Tech
  • 6 Topics
  • 50 Offline Downloads
  • Uploaded 5 months ago
Akhil Krishna
Akhil Krishna
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-2

Design Patterns CONTENTS UNIT-1 UNIT-2 UNIT-3 UNIT-4 UNIT-5 UNIT-6 R a j e s h D e s i g n P a t t e r n s

Text from page-3


Text from page-4

Introduction to Design Patterns What Is a Design Pattern? 1. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". 2. In software engineering, A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. In general, a pattern has four essential elements: 1. Pattern Name  It is a handle we can use to illustrate a design problem, its solutions, and consequences in a word or two.  Naming a pattern instantly increases our design vocabulary. It lets us design at a higher level of abstraction.  It makes it easier to think about designs and to communicate them and their trade- offs to others.  Finding good names has been one of the hardest parts of developing our catalog. 2. Problem  It describes when to apply the pattern.  It explains the problem and its context.  It might describe specific design problems such as how to represent algorithms as objects.  It might describe class or object structures that are indicative of an inflexible design.  Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern. 3. Solution  It describes the elements that make up the design, their relationships, responsibilities, and collaborations.  The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations.  Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it. 4. Consequences:  They are the results and trade-offs of applying the pattern.  Though consequences are often understood when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern.  The consequences for software often concern space and time trade-offs.  They may address language and implementation issues as well.  Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability.  Listing these consequences explicitly helps you understand and evaluate them. Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. 2|R a j e s h Design Patterns 002

Text from page-5

The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.  A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design.  The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.  Each design pattern focuses on a particular object-oriented design problem or issue.  It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.  Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++ rather than procedural languages(Pascal, C, Ada) or more dynamic object-oriented languages (CLOS, Dylan, Self).  The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily.  If we assumed procedural languages, we might have included design patterns called  "Inheritance", "Encapsulation," and "Polymorphism." Design Patterns in Smalltalk MVC The Model/View/Controller (MVC) triad of classes is used to build user interfaces in Smalltalk-80.MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to combine these objects together. MVC decouples them to increase flexibility and reuse.  MVC decouples views and models by establishing a subscribe/notify protocol between them.  A view must ensure that its appearance reflects the state of the model.  Whenever the model's data changes, the model notifies views that depend on it.  In response, each view gets an opportunity to update itself.  This approach lets you attach multiple views to a model to provide different presentations.  We can also create new views for a model without rewriting it. The following diagram shows a model and three views. Model  The model contains some data values, and the views defining a spreadsheet, histogram, and pie chart display these data in various ways.  The model communicates with its views when its values change, and the views communicate with the model to access these values. This example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer design pattern. 3|R a j e s h Design Patterns 003

Lecture Notes