Design Patterns - Speaker Deck

Slide 1

Slide 1 text

Design Patterns Advanced Topics in Software Engineering

Slide 2

Slide 2 text

Principles of Object-orientation • Abstraction - Simplify and generalizes entities • Encapsulation - Separation of concerns and information hiding • Modularization - Cohesive and loosely-coupled abstractions • Hierarchy - Hierarchical organization of abstractions

Slide 3

Slide 3 text

A motivating Example • There is the Software Engineering in Practice Course and a few stakeholders (Students and Instructors) • Any change in the course must be notified to all the stakeholders • Now, think about its implementation

Slide 4

Slide 4 text

A motivating Example (2)

Slide 5

Slide 5 text

Implementation

Slide 6

Slide 6 text

Implementation (2) • Is it easy to add a new observer (a new Student or a new Instructor)? • You need to make multiple changes • What about adding a new category of observers; for example "Organizer"!

Slide 7

Slide 7 text

Implementation – Take 2

Slide 8

Slide 8 text

A motivating example (3) • Now, think again about adding new observers. • Is it easier? • In the first implementation, `Course` class is "tightly-coupled" to `Student` and `Instructor` classes. While in the second case, `Course` class is "loosely-coupled" to it's observers. • Congratulations!! You have just learned the first design pattern :)

Slide 9

Slide 9 text

The Implemented Solution

Slide 10

Slide 10 text

Observer Design Pattern

Slide 11

Slide 11 text

Observable and Observer (in Java)

Slide 12

Slide 12 text

Let Us Define Design Patterns • Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. (By Gang of Four) • Design patterns are solutions to commonly occurring design problems.

Slide 13

Slide 13 text

Essential Elements of Patterns • Name • Problem • Problem and context • Solution • Relationships, roles, and responsibilities • Consequences • Benefits and liabilities • Tradeoffs

Slide 14

Slide 14 text

Why to Use Patterns • Higher design quality • Flexibility • Changeability • Testability • ... • Common vocabulary

Slide 15

Slide 15 text

Categories of Patterns • Creational - patterns answer how to create and when to create • Examples: Factory, Abstract Factory, Builder • Structural - patterns answer how to compose/structure • Examples: Adapter, Composite, Decorator • Behavioral - patterns describe how a group of objects cooperate to carry out a task • Examples: Observer, Strategy, Visitor

Slide 16

Slide 16 text

Exercise 1 • In the context of the SEiP course, there is a course, students, instructors, and organizers. • The course has a start time and end time. • If any of the timing changes, the stakeholders have to be notified. Implement a program that notifies the stakeholders whenever the time changes for the course.

Slide 17

Slide 17 text

Exercise 2 • Write a Utility class for reading a text file and writing to a text file.

Slide 18

Slide 18 text

Exercise 3 • Write a program to compute following metrics for Java code: • LOC (Lines of Code) • Number of classes • Number of methods. • Write the metrics in a file. • Use regular expressions to calculate the aforementioned metrics. • Use the read & write methods from the Utility class created in Exercise 2.

Slide 19

Slide 19 text

Design Patterns Part-2 Advanced Topics in Software Engineering

Slide 20

Slide 20 text

Let us use time machine to go one week back and revisit patterns quickly

Slide 21

Slide 21 text

Design Patterns: Definition • Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. (By Gang of Four) • Design patterns are solutions to commonly occurring design problems.

Slide 22

Slide 22 text

Essential Elements of Patterns • Name • Problem • Problem and context • Solution • Relationships, roles, and responsibilities • Consequences • Benefits and liabilities • Tradeoffs

Slide 23

Slide 23 text

Why to Use Patterns • Higher design quality • Flexibility • Changeability • Testability • ... • Common vocabulary

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Let us use time machine again and come back to the present J

Slide 26

Slide 26 text

Factory Pattern • Motivation • Creating objects without exposing the instantiation logic to the clients • Providing a common interface to refer all objects (of a kind)

Slide 27

Slide 27 text

Factory Pattern

Slide 28

Slide 28 text

Factory Pattern - Example

Slide 29

Slide 29 text

Factory Pattern • Benefits • Separation of concerns - the logic to instantiate classes is separated • Flexibility - to extend Product hierarchy without affecting clients • Liabilities • Don't bypass

Slide 30

Slide 30 text

Let us extend the Factory pattern • Motivation • Let us assume you have families of objects to instantiate • Widget library providing UI elements such as Button and TextBox • The library instantiate UI elements based on the platform such as Windows and Linux

Slide 31

Slide 31 text

Abstract Factory Pattern

Slide 32

Slide 32 text

Abstract Factory Pattern • Benefits • Flexibility (Entire product families can be easily exchanged) • Separation of concerns (Object lifetime management is separated from object use) • Liabilities • GoF Abstract Factory only covers object creation, not object disposal

Slide 33

Slide 33 text

Strategy Pattern • Motivation • Support for more than one algorithm required in many situations: • Clients do not want to be dependent on a supplied default algorithm • Suitability of an algorithm may change based on the context (input, platform, ...) • Integrating new algorithms should be easy (without modifying existing code, if possible) • Examples • Compression algorithm, sort algorithm

Slide 34

Slide 34 text

Strategy Pattern

Slide 35

Slide 35 text

Strategy Pattern • Benefits • Freedom to choose algorithms • Easier extensibility • Applicability • Many related classes differ only in their behavior • You need different variants of an algorithm • A class defines many behaviors, and these appear as multiple conditional statements in its operations

Slide 36

Slide 36 text

Composite Pattern

Slide 37

Slide 37 text

Composite Pattern • Motivation • Need to represent “whole-part” hierarchies with following requirements • Preserve hierarchical structure • Same interface for both compound or atomic objects for clients • It should be easy to extend the hierarchy with new element types

Slide 38

Slide 38 text

Composite Pattern

Slide 39

Slide 39 text

Composite Pattern

Slide 40

Slide 40 text

Composite Pattern • Benefits • Transparency (Clients are shielded from the object hierarchy) • Extensibility (New leafs are easy to add)

Slide 41

Slide 41 text

Façade Pattern • Motivation • Let us assume that we have a component that provide complex multi-steps services • How to provide a client simplified access to the functionality of such a component

Slide 42

Slide 42 text

Façade Pattern

Slide 43

Slide 43 text

Façade Pattern • Benefits • Provides a simple interface to a complex system • De-couples the subsystem for clients and other subsystems, thereby promoting subsystem independence and portability • Layers the subsystem • Use façade to define an entry point to each subsystem level • If subsystems are dependent, then the dependencies between them can be simplified by making them communicate with each other solely through their facades

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Exercises 3. Complete exercise 1, 2, and 3 4. Provide another way to implement the same functionality but by using string comparison. Pay attention to your design (hint: implement strategy and factory patterns) 5. Extend the above program and implement a segregated interface to compute all the supported metrics. Write all the computed metrics to a CSV file. (hint: use Facade pattern) Deadline: 25 May, 2017

Slide 47

Slide 47 text

Courtesy: spikedmath.com Thank you!!