1. Intent and motivation of Façade Design Pattern?

Intent:

Provide a unified interface to a set of interfaces in a subsystem. Facade defines

a higher-level interface that makes the subsystem easier to use

Motivation:

Structuring a system into subsystems helps reduce complexity. A common

design goal is to minimize the communication and dependencies between subsystems.

One way to achieve this goal is to introduce a facade object that provides a single,

simplified interface to the more general facilities of a subsystem.

Consider for example a programming environment that gives applications

access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser,

Program Node, Byte code Stream, and Program Node Builder that implement the compiler.

Some specialized applications might need to access these classes directly. But most clients of

a compiler generally don't care about details like parsing and code generation; they merely

want to compile some code. For them, the powerful but low-level interfaces in the compiler

subsystem only complicate their task.

2. Consequences of Proxy Design Pattern?

Consequences:

– Efficiency: avoids time-consuming operations when necessary.

– Correctness: separates design and code that are independent of

retrieval/efficiency from parts concerned with this issue.

– Reusability: design and code that are independent of retrieval efficiency are

most likely to be reusable.

– Flexibility: we can replace one module concerned with retrieval with another.

– Robustness: isolates parts that check for the validity of retrieved data.

– The penalties we pay can sometimes be too high:

If the proxy forces us to keep very large amount of data in the memory

and its use is infrequent.

3. Structure and Motivation of Chain of Responsibility?

Motivation: Consider a context-sensitive help facility for a graphical user interface.

The user can obtain help information on any part of the interface just by clicking on it.

The help that's provided depends on the part of the interface that's selected and its

context; for example, a button widget in a dialog box might have different help

information than a similar button in the main window. If no specific help information

exists for that part of the interface, then the help system should display a more general

help message about the immediate context—the dialog box as a whole, for example.

The Button, Dialog, and Application classes use Help Handler operations to handle help

requests. Help Handler's Handle Help operation forwards the request to the successor by

default. Subclasses can override this operation to provide help under the right circumstances;

otherwise they can use the default implementation to forward the request

Structure:

4. Consequences of Command Design Pattern?

Consequences:

a. The object of the command (Receiver) and the algorithm of the command

(ConcreteCommand) are decoupled.

b. Invoker is shielded from specific commands.

c. Concrete Commands are objects. They can be created and stored.

d. New Concrete Commands can be added without changing existing code.

e. You have commands that need to be

executed,

undone, or

queued

f. Command design pattern separates Receiver from Invoker from Commands

g. All commands derive from Command and implement do(), undo(), and redo()

5. What are behavioural Pattern?

Behavioral patterns are concerned with algorithms and the assignment of

responsibilities between objects. Behavioral patterns describe not just patterns of

objects or classes but also the patterns of communication between them.

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento,

Observer, State, Strategy, Template Method, Visitor.

6. Structure and participants of Memento design pattern?

Participants:

• Memento

– Stores internal state of the Originator object. Originator decides how much.

– Protects against access by objects other than the originator.

– Mementos have two interfaces:

• Caretaker sees a narrow interface.

• Originator sees a wide interface.

• Originator

– Creates a memento containing a snapshot of its current internal state.

– Uses the memento to restore its internal state.

Caretaker

- Is responsible for the memento’s safekeeping.

- Never operates on or examines the contents of a memento.

7. When to use State Design Pattern?

State pattern is useful when there is an object that can be in one of several states,

with different behavior in each state.

To simplify operations that have large conditional statements that depend on the

object’s state.

8. A Brief History of Design Pattern?

o 1979--Christopher Alexander pens The Timeless Way of Building

i. Building Towns for Dummies

ii. Had nothing to do with software

o 1994--Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the

Gang of Four, or GoF) publish Design patterns: Elements of Reusable Object-

Oriented Software

Capitalized on the work of Alexander

The seminal publication on software design patterns

9. Motivation of Strategy Design Pattern?

Many algorithms exist for breaking a stream of text into lines. Hard-wiring all such

algorithms into the classes that require them isn't desirable for several reasons:

· Clients that need linebreaking get more complex if they include the linebreaking

code. That makes clients bigger and harder to maintain, especially if they support

multiple linebreaking algorithms.

· Different algorithms will be appropriate at different times. We don't want to support

multiple linebreaking algorithms if we don't use the mall.

· It's difficult to add new algorithms and vary existing ones when linebreaking is an

integral part of a client.

water StateOfWater

WaterVapor LiquidWater Ice

increaseTemp()decreaseTemp()

state variable

increaseTemp()decreaseTemp()

increaseTemp()decreaseTemp()

increaseTemp()

decreaseTemp()

increaseTemp()decreaseTemp()

We can avoid these problems by defining classes that encapsulate different

linebreaking algorithms. An algorithm that's encapsulated in this way is called a

strategy.

10. Intent and motivation of Observer Design pattern?

Intent

Define a one-to-many dependency between objects so that when one object changes state, all

its dependents are notified and updated automatically.

Motivation:

A common side-effect of partitioning a system into a collection of cooperating classes

is the need to maintain consistency between related objects. You don't want to achieve

consistency by making the classes tightly coupled, because that reduces their reusability.

For example, many graphical user interface toolkits separate the presentational aspects of the

user interface from the underlying application data.Classes defining application data and

presentations can be reused independently. They can work together, too. Both a spreadsheet

object and bar chart object can depict information in the same application data object using

different presentations. The spreadsheet and the bar chart don't know about each other,

hereby letting you reuse only the one you need. But they behave as though they do. When the

user changes the information in the spreadsheet, the bar chart reflects the changes

immediately, and vice versa.