Design Patterns in CSE 403, Lecture notes of Compiler Design

An outline of the CSE 403 course on Design Patterns. It covers the introduction to design patterns, creational patterns, structural patterns, and behavioral patterns. The document also includes examples of subclassing, iteration, and exceptions. Additionally, it provides tips for designing generic classes and when to use design patterns. The document concludes with a discussion on factories and their implementation.

Typology: Lecture notes

2021/2022

Uploaded on 05/11/2023

elmut
elmut 🇺🇸

4.6

(16)

285 documents

1 / 40

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSE 403
Design Patterns
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28

Partial preview of the text

Download Design Patterns in CSE 403 and more Lecture notes Compiler Design in PDF only on Docsity!

CSE 403

Design Patterns

Outline Introduction to design patternsCreational patterns (constructing objects)Structural patterns (controlling heap layout)Behavioral patterns (affecting object semantics)

Example 1: Encapsulation (data hiding) Problem: Exposed fields can be directly manipulated^ Violations of the representation invariantDependences prevent changing the implementationDependences prevent changing the implementation Solution: Hide some components^ Permit only stylized access to the object

y^ y

j

Disadvantages:^ Interface may not (efficiently) provide all desired operationsI di

i

d^

f

Indirection may reduce performance

Example 2: Subclassing (inheritance) Problem: Repetition in implementations^ Similar abstractions have similar members (fields, methods) Solution: Inherit default members from a superclass^ Select an implementation via run-time dispatching Disadvantages:Disadvantages:

Code for a class is spread out, and thus less understandableRun-time dispatching introduces overhead

Example 4: Exceptions Problem:^ Errors in one part of the code should be handled elsewhere.Code should not be cluttered with error handling codeCode should not be cluttered with error-handling code.Return values should not be preempted by error codes. Solution: Language structures for throwing and catching

g^ g

g^

g

exceptionsDisadvantages:^ C d

ill b^

l^

d

Code may still be cluttered.It may be hard to know where an exception will behandled.Use of exceptions for normal control flow may beconfusing and inefficient.

Slide 7

Example 5: Generics Problem:^ Well-designed data structures hold one type of object Solution:^ Programming language checks for errors in contents^ List

instead of just

Listj

Disadvantages:^ Slightly more verbose types

Tips for designing generic classes First, write and test a concrete version^ Consider creating a second concrete version Then, generalize it by adding type parameters^ The compiler will help you to find errors

A puzzle about generics

Integer is a subtype of NumberList is not a subtype of List^ Compare specs: add(Integer) is not stronger than add(Number)What goes wrong if List is a subtype of List?What goes wrong if List is a subtype of List?^ List

li^

=^ new

List();

//^ legal

if^

List

is^

subtype

of^

List

List ln

=^ li;

List ln

li;

ln.add(new Float());li.get(0);

//^

we^ got

a^ Float

out

of^

a^ List!

Integer[] is a subtype of Number[]^ Can we use similar code to break the Java type system?

Why should you care? You could come up with these solutions on your ownYou shouldn't have to!A design pattern is a known solution to a known problem

Creational patterns Constructors in Java are inflexible^ Can't return a subtype of the class they belong toAlways return a fresh new object never re use oneAlways return a fresh new object, never re-use one FactoriesFactories^ Factory methodFactory objectPPrototype Sharing^ SingletonSingleton^ InterningFlyweight

Motivation for factories: Changing implementations Supertypes support multiple implementations^ interface

Matrix

{^ ...

}

class

SparseMatrix

implements

Matrix

{^ ...

}

class DenseMatrix

implements

Matrix

{^

}

class DenseMatrix

implements

Matrix

{^ ...

}

Clients use the supertype (Matrix)^ Still need to use a

SparseMatrix

or^ DenseMatrix

constructor

Switching implementations requires code changes

Use of factories Factory^ class MatrixFactory {

public static Matrix createMatrix() {public static Matrix createMatrix() {return new SparseMatrix();} } Clients call createMatrix, not a particular constructorAdAdvantages^ To switch the implementation, only change one placeCan decide what type of matrix to create

yp

Example: Tour de France class TourDeFrance

extends

Race

{

//^ factory

method Race

createRace()

{

Bicycle

bike

=^ new

RoadBicycle();

Bicycle

bike

=^ new

RoadBicycle();

...} }}

Example: Cyclocross class Cyclocross

extends

Race

{

//^ factory

method Race

createRace()

{

Bicycle

bike

=^ new

MountainBicycle();

Bicycle

bike

=^ new

MountainBicycle();

...} }}