Dept. of Computer Engineering, Amir-Kabir University 1 Design Patterns Dr. Noorhosseini Lecture 2.

Dept. of Computer Engineering, Amir-Kabir University

1

Design PatternsDr. Noorhosseini

Lecture 2


2

Review of some OO concepts

Encapsulation:

Object packages both data and procedures (called methods or operations). It performs an operation when it receives request (or messages) from a client. Request are the only way to get an object to do an operation. Operations are the the only way to change object’s internal data. So the internal state of an object is said to be encapsulated.


3

Review cont...

- Operation signature (name , objects for parameters, returned objects)

- The set of all signatures defined by an object’s operations is called the interface to the object.

- Type: a name denoting a particular interface. (e.g type “window”, if it accepts all requests for interface “window”). An object may have many types and many object can share the same type.

- Subtype, supertype : subtype inheriting its `supertype


4

Review cont..

- Dynamic binding: Run-time association of a request to an object and of it’s operations. (Different objects that support identical requests may have different implementations of the operations.)

- Polymorphism: Dynamic binding let’s you substitute objects with similar interfaces at run-time. This in known as polymorphism, a key concept in OO systems.


5

Review cont..

Class inheritance versus Interface inheritance - Difference between an object’s class and it’s type :

type only refers to it’s interface, objects of different classes can have the same type

- Class inheritance is a mechanism for code and representation sharing.

- Interface inheritance describes when an object can be used in place of another.

- C++ use classes to specify both type and it’s implementation. So it does not distinguish the difference.

- Java, recognizes the difference.


6

Review cont..

Object implementation - Object instantiation: object are created by

instantiating a class. (allocating memory to hold instance variables) (UML notation)

- Class inheritance: Subclass inheriting from a parent class (UML notation)

- Abstract class, concrete class, abstract operations - Overriding an operation defined by parent class. - Mixin class, a class that is intended to provide

optional interfaces to other classes and not to be instantiated.


7

Review cont..

Aggregation and Association- Aggregation means on object owns another object

(having or being part of) It implies that an aggregate object and its owner

have identical lifetimes.

- Association (acquaintance, using ) means that object knows another object. They use each others operations but they are not responsible for each other. They have different lifetimes (UML diagram)


8

OO Design problems

Finding Appropriate Objects

- The hard part about OO design is decomposing a system into objects. Why?

- many factors are involved: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, etc.

- Many objects come from the analysis model. But we often end up with classes that has no counterpart in the real world. Strict modeling of the world leads to a design that reflect today’s need and not necessarily future.

- Abstraction is a way to treat objects that do not have a physical counterpart. Design patterns help you identify less obvious abstractions and objects that can capture them.


9

OO design problems (cont..)

Determining Granularity

- How do we decide what should be an object? In what granularity?

- Design Patterns address this issue as well. Façade pattern describe how to present complete subsystems as objects.


10


Specifying object interfaces

- What should be the messages?

- Design patterns help defining interfaces by determining the type of data that gets sent across interfaces. Memento pattern for example defines two interfaces: a restricted one that hold and copy mementos and one privileged one that only original object can use to store and retrieve state.


11


- Object instantiations, Class hierarchy, inheritance , what should be the abstract classes and what should be concrete classes,etc..

-Patterns such as Composite, Abstract factory,

chain of responsibility address these issues.


12

Principals behind Design patterns

Programming to an interface, not an implementation

- Class inheritance gives the ability to define new objects in terms of an old one (get free implementation for most of what you need).

- Another purpose is getting identical interfaces by inhering from an abstract class (polymorphism depends on it).

-


13

Principals Cont..

- all classes derived from an abstract class simply override interfaces and therefore they can all respond to the requests to the abstract class (I.e they are all subtypes)

- Two benefits:

1- clients remain unaware of the specific type of objects they use.

2- classes remain unaware of the classes that implement these objects

- (in Short clients need only know the abstract classes)


14

Principals cont..

This leads us to the first good design principle:

Program to an Interface, not to an implementation

Consequences: - Don’t declare variables to be instances of a concrete classes, instead commit

only to interfaces of an abstract class.

Creational patterns ensure that your system is written in terms of interfaces, not implementations.


15

Principals cont..

Inheritance versus composition

- White-box reuse: Reuse by subclassing (The internals of parent classes visible to subclasses)

- An alternative to class inheritance to get more complex functionality: object composition

- Composition requires that objects being composed to have well-defined interfaces.

- Black-box reuse: Reuse by composition (no internals of objects are visible).


16

Principals cont.. Advantages and disadvantages of both: -Ad: Class inheritance is defined statically at compile

time, easy to use since it has the language support. Easy to modify implementation by overriding some operations:

- Dis: Can not change inherited implementation at runtime (its defined at compile time).

worse: Inheritance breaks encapsulation. Any change to parent implementation will force subclasses to change. Implementation dependency makes reuse of subclasses very limited, as any change to subclasses need to change parents.


17

Principals cont..

. Object Composition is defined dynamically at runtime trough acquiring references to other objects

- We do not break encapsulation because objects are accessed solely through interfaces (but that means some effort on good interface design)

- Any object can be replaces with another at runtime

as long as it has same type. - Implementation written in terms of interfaces so

much less implementation dependency


18

Principals cont..

Another principle:

Favor object composition over class inheritance

Consequences:

Helps keep each class encapsulated and focused on one task. Classes and class hierarchies will remain small and more manageable.

A design with composition will have more objects and system behavior will depend on their interrelationship rather than defined in one class.


19

Principals Cont.. Note:

- Inheritance and composition work together

- Designers tend to over use inheritance to achieve new functionality

- Designs are made more reusable and simpler by depending more on object composition.


20

Principals cont..

Delegation- A way to making composition powerful for reuse. - Two objects are involved in handling a request: one object

receives the request, and delegates the request to be handled by its delegate. (the receiver passes a reference to itself to the delegate)

- Example : Window and Rectangle objects (instead of using inheritance, instead of window being a rectangle, it can have a rectangle


21

Principals cont.. The main advantage of delegation is that it makes it easy to

compose behaviors at run-time (e.g window can become circle instead of rectangle, by simply replacing the instances if they are the same type)

- Disadvantage: Dynamic, highly parameterized software is hard to read and understand.

Delegation is a good design choice when it simplifies more that it complicates.

- Delegation works best if it’s used in highly stylized ways – that is in standard patterns (State, Strategy and visitor patterns rely on delegation).


22

Principals cont.. Inheritance versus Parameterized Types- Parameterized Type: another technique for reuse also

known as Templates (C++, Java).- Let you define a type without specifying other types it uses.

The unspecified types are supplied as parameters at the point of use. (example : a list class) (Template Method pattern use this technique)

- Important differences: Object composition let you change the behavior at run time. Neither inheritance nor parameterized types can change at runtime.

- Inheritance provide default implementation for operations, templates let you change the type a class uses.


23

Run-time and Compile-time Structures Basically no resemblance in OO programs. Trying to understand run-time behavior from static code is

like to understand an ecosystem from the taxonomy of plants and animals

Code won’t reveal everything about how the system will work. The system run-time behavior must be imposed by designer than by language.

Design patterns help to impose the behavior at run-time. Composite and Decorator patterns are especially useful for building complex run-time structures.

In general run-time structures aren’t clear from code unless you understand the pattern.


24

Designing for Change

A design that does not take change into account risks a major redesign in the future.

Each design pattern lets some aspect of system structure vary independently of the other aspects, making system more robust to a particular type of change.


25

Common causes of change that are addressed by design pattern 1- Creating an object by specifying a class explicitly

(committing to an implementation not to an interface)

- solution create an object indirectly; subject of Abstract Factory, Factory Method, Prototype patterns

2- Dependence on specific operations. (committing to one way of responding to a request)

- solution: avoid hard-coded request; Chain of responsibility, Command patterns


26

Common.. 3- Dependence on hardware and software platform. porting problem from on platform to the other, different OS or

different HardwareSolution: Design with no (limited) platform dependencies;

Abstract factory and Bridge patterns

4- Dependence on object representations or implementations Solution: Hide this information from clients; Abstract Factory,

Bridge, Memento, Proxy patterns

5- Algorithmic dependencies Solution: Algorithms must be isolated; Strategy, Builder,

Iterator, Visitor and Template Method


27

Common …6- Tight coupling – Changes in one class requires changes in

many other. Solution: Loose coupling, abstract coupling and layering;

Abstract Factory, Bridge, Chain of Responsibility, Command, Façade, Mediator, Observer

7- Extending functionality by subclassing Solution: Object Composition and delegation; Composite,

Decorator, Observer, Bridge, …

8- Inability to change classes (no access to source ,commercial class library),

Adapter, Decorator, Visitor


28

Framework and patterns Framework is a set of cooperating classes that make of

reusable design for a specific class of software. It usually contains concrete classes that can be used as is. It’s a pre-determined architecture for a particular application

Patterns and Frameworks are different:

1- Design patterns are more abstract than framework

2- Design patterns are smaller architectural elements, a typical framework uses several patterns

3- Design patterns are less specialized


29

How to select a design pattern Consider how a pattern solves a design problem Study the intent Study Interrelations of patterns Study the class of pattern (structural, behavioral,

creational) Examine the causes of redesign Consider what should be Variable in your design

Date post:	21-Dec-2015
Category:	Documents
View:	214 times
Download:	1 times

Dept. of Computer Engineering, Amir-Kabir University 1 Design Patterns Dr. Noorhosseini Lecture 2.

Documents