program design, design patterns, type theory, and other buzzwords. amr sabry عمرو صبرى...

52
Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry رى صب رو م عIndiana University

Upload: marcia-hines

Post on 13-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

Program Design,Design Patterns,

Type Theory,and other buzzwords.

Amr Sabry

صبرى عمروIndiana University

Page 2: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory2

Playing Music

Page 3: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory3

Building Structures

Page 4: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory4

Programming

(define fact

(lambda (n)

(if (zero? n)

1

(* n (fact (sub1 n))))))

Page 5: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory5

Levels of Abstraction

As programmers we must deal with different levels of abstraction

Write little pieces of code, encapsulate them by hiding the irrelevant details, and describing their behavior in concise terms.

Use these encapsulations as building blocks for the next

layers of abstraction, etc.

Page 6: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory6

Outline

Part I

Abstraction and Reuse

Part II

Abstraction and Safety

Page 7: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

Part I

Abstraction and Reuse

Page 8: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory8

Reuse

Do we want to “reuse” code? YES!!!

We earlier said:

Write little pieces of code, encapsulate them by hiding

the irrelevant details, and describing their behavior in concise terms.

What is “irrelevant” depends on how the code will be used!!!

Page 9: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory9

Which is an abstraction of a human?

Page 10: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory10

Reuse (unanticipated)

If we choose one particular abstraction, then we essentially rule out some future uses of the software.

Unfortunately people like to modify software after the fact in unpredictable ways!

Page 11: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory11

Architecture and Design Patterns

Christopher Alexander

Design of a building is tied to the anticipated uses and must be flexible to accommodate other emerging uses.

The uses are captured in pattern languages and all buildings are the result of applying sets of rules (or pattern languages - sets of related patterns)

Alexander's Patterns

a pattern is a formalized instruction that says: "if you encounter this problem, then solve it like that" patterns are the means to an end or rules of thumb patterns are used in combination, with cross-referencing, enabling decisions to be made in a reasonable

order

Software Design Patterns "These patterns solve specific design problems ... 

make object-oriented designs more flexible, elegant and ultimately reusable ...  basing new designs on prior experience ... without having to rediscover them ... “ (Gamma et al. 1995) 

Page 12: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory12

Warning!

Lots of details to follow!

Page 13: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory13

A Design Problem

McSabry food chain needs a program to keep track of the food items it sells.

Initially, McSabry will focus on: ice cream, hotdogs, and pizza.

For each food item, we will need to keep track of its cost and selling price so that we can compute the profit from sales.

Page 14: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory14

An Initial Java Design

FoodItem

IceCream Hotdog Pizza

CostPrice

Page 15: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory15

Java Implementation

abstract class FoodItem { abstract int cost (); abstract int price();}

class HotDog … { … }

class Pizza … { … }

class IceCream extends FoodItem {

int cost () { return 1; }

int price () { return 5; }}

Page 16: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory16

Sales and Profit

class Profit { int profit (FoodItem[] sales) { int totcost = 0; int totprice = 0; for (int i=0; i<sales.length; i++) { totcost += sales[i].cost(); totprice += sales[i].price(); } return totprice – totcost; }}

Page 17: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory17

McSabry expands…

McSabry decides to add Vegetables to its food items.

We need to modify the design and the program!

Page 18: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory18

Updated Design

FoodItem

IceCream Hotdog Pizza

CostPrice

Vegetables

Page 19: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory19

Updated Implementation

class Vegetables extends FoodItem {

int cost () { return 2; }

int price () { return 4; }

}

Code already written does NOT have to change at all!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Page 20: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory20

FDA

Unfortunately McSabry discovered recently that the FDA requires that the company reports the number of calories in every food item.

Need to modify the design and program again!

Page 21: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory21

Updated Design

FoodItem

IceCream Hotdog Pizza

CostPriceCalories

Vegetables

Page 22: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory22

Updated Implementation

Oops!

Must go back and change EVERY class that we have written.

Scale this to millions of line of code

Let’s revise our original design…

Page 23: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory23

The problem

We did not anticipate reuse in one dimension.

How could we modify the design to accommodate growth not only in new food items but also in new operations on food items.

Solution: the Visitor Pattern.

Page 24: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory24

Visitor Pattern

FoodItem

IceCream Hotdog Pizza

acceptVegetables

FoodVis

CostVis PriceVis CaloriesVis

visitIceCreamvisitHotDogvisitPizzavisitVegetables

Page 25: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory25

Implementation

class IceCream extends FoodItem {

int accept (FoodVis fv) { return fv.visitIceCream(); }

}

class PriceVis extends FoodVis { int visitIceCream () { return 5; } int visitVegetables () { return 4; } …}

Page 26: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory26

Extensible Reusable Code

Possible to add new operations on food items without changing any existing code.

With another small modification, it is possible to add more food items without changing any existing code.

Page 27: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory27

Summary of Part I

Before we can “abstract” we must decide what is “relevant” and what is “irrelevant.” Need design experience, patterns, etc.

Most CS courses teach abstraction. Focus on reuse comes in class that focus on programming in the large, software engineering, and OO design.

Page 28: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

Part II

Abstraction and Safety

Page 29: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory29

Programming with Abstractions

Assuming we have already decided what is relevant and what is irrelevant, how do really hide the irrelevant details and be sure they will not somehow leak out?

Page 30: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory30

Types

Types are a syntactic discipline for enforcing levels of abstractions [Reynolds]

Not comments

Part of the programming language

Checked and enforced by the compiler

Page 31: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory31

Interfaces (from Java 2)

public interface Collection { boolean add (Object o); bollean addAll (Collection c); void clear (); boolean contains (Object o); boolean containsAll (Collection c); boolean equals (Object o); int hashCode (); boolean isEmpty (); Iterator iterator (); boolean remove (Object o); boolean removeAll (Collection c); boolean retainAll (Collection c); int size (); Object[] toArray (); Object[] toArray (Object[] a);}

Page 32: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory32

Type Safety

Informal:

If the compiler determines that some expression has type T, then it will have type T at runtime.

No unanticipated errors.

Bad example:

Compiler determines that e has type int

Hence ok to write 1+e

But e evaluates to an array of booleans.

Page 33: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory33

Example in C (I)

[From Intensional Equality for Continuations by Andrew Appel]

A function in a high-level programming language is just the address of an instruction at the machine level. In C one can mix high-level functions and unsigned numbers!!!

Page 34: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory34

Warning!

Lots of details to follow!

Page 35: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory35

Example in C (II)

cMain (int ac, char*av[]) { int i,j; (void) srandom (atoi (av[1])); for (i=0; i < 10000000; i++) { j = quickroot (random()); } exit(0);}

eMain() {}

unsigned mycaller[] = { 0x81c3e008,0x9010001f };

Page 36: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory36

Example in C (III)

int quickroot (int i) { static x = 0; if (x) return cbrt (i); x=1; { unsigned *p, *q, caller; union { unsigned *z; unsigned (*f)(); } u; u.z = mycaller; caller = u.f();

if (caller <= (unsigned)main ||

caller >= (unsigned)main +

(unsigned)eMain -

(unsigned)cMain)

return quickroot(i);

}

exit(0);

}

Page 37: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory37

What’s going on?

Layout: If main == cMain then

do nothing

If main is anything else then call the real cbrt function

main

quickroot

Page 38: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory38

Why is this Bad?

The types don’t hide anything!

Unanticipated errors can happen

Evaluation can even proceed with nonsense

No abstraction

Page 39: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory39

Why is it REALLY Bad?

From Securing Java, John Wiley & Sons, Inc.

The Java language is designed to enforce type safety. This means that programs are prevented from

accessing memory in inappropriate ways… Type safety means that a program cannot perform an operation on an object unless that operation is valid for that object.

Type safety is the most essential element of Java’s security… In our experience, every type safety violation has created an opportunity for an untrusted applet to break out of Java’s security restrictions.

Page 40: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory40

Safety with a Straightjacket

Pascal was safe (almost!)

Pascal’s type system was very limited (a function that sorts an array of ints cannot sort an array of floats)

Need expressive type system that is safe.

Here lies Pascal: A Language

Chocked by its Type System

Page 41: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory41

An Expressive & Safe Type System: Haskell

Lookup :: (Eq a) =>

a -> [(a,b)] -> Maybe b

lookup key [] = Nothing

lookup key ((x,y):xys)

| key == x = Just y

| otherwise = lookup key ys

There are even more advanced type systems but they are not part of “mainstream” programming languages

Hot research topic with new proposals emerging every year

Page 42: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory42

Haskell primitive types

[Based on tutorial on haskell.org] 5 :: Integer ‘a’ :: Char inc :: Integer -> Integer

inc n = n+1 [1,2,3] :: [Integer] (‘b’,4) :: (Char, Integer)

Page 43: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory43

Polymorphic Types

length :: forall a. [a] -> Integer

length [] = 0

length (x:xs) = 1 + length xs

length [1,2,3] 3 length [‘a’, ‘b’, ‘c’] 3 length [[1,5], [2,5], [3,5]] 3

Page 44: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory44

User-Defined Types

data Bool = False | True data Color = Red | Green | Blue | Indigo data Point a = Pt a a

Pt 2.0 3.0 :: Point Float Pt ‘a’ ‘b’ :: Point Char Pt True False :: Point Bool Pt ‘a’ 1 :: TYPE ERROR

Page 45: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory45

Recursive Types

data Tree a = Leaf a | Branch (Tree a) (Tree a)

Branch :: Tree a -> Tree a -> Tree a Leaf :: a -> Tree a

fringe :: Tree a -> [a]

fringe (Leaf x) = [x]

fringe (Branch left right) = fringe left ++ fringe right

Page 46: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory46

Type Classes

class Eq a where (==) :: a -> a -> Bool instance Eq Integer where x == y = x `integerEq` y instance Eq Float where x == y = x `floatEq` y instance (Eq a) => Eq (Tree a) where Leaf a == Leaf b = a == b (Branch l1 r1) == (Branch l2 r2) = (l1 == l2) && (r1 == r2) _ == _ = False

Page 47: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory47

Modules

module Tree (Tree(Leaf,Branch), fringe) where

data Tree a = Leaf a | Branch (Tree a) (Tree a)

fringe :: Tree a -> [a] fringe (Leaf x) = [x] fringe (Branch l r) = fringe l ++ fringe r

module Main (main) where

import Tree( Tree(Leaf,Branch), fringe)

main = print (fringe (Branch (Leaf 1) (Leaf 2)))

Page 48: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory48

Existential Types

module TreeADT (Tree, leaf, branch, cell, left, right, isLeaf) where-- We know there exists a type Tree but representation is HIDDEN

data Tree a = Leaf a | Branch (Tree a) (Tree a)

leaf = Leafbranch = Branchcell (Leaf a) = aleft (Branch l r) = l right (Branch l r) = risLeaf (Leaf _) = TrueisLeaf _ = False

Page 49: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory49

Monads & Memory Encapsulation

new :: forall a. a -> ST s (Ref s a) read :: forall a. Ref s a -> ST s a write :: forall a. Ref s a -> a -> ST s () runST :: forall a. (forall s. ST s a) -> a

If (runST e) typechecks then:– e does not use any memory allocated from the outside– The memory allocated by e is not visible on the outside.

Can evaluate e on a local processor Can immediately reclaim the memory used by e etc

Page 50: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory50

And so on …

Parametricity Theorem for Haskell (informal)

If a program typechecks then it is likely to be correct!!!!!!

Intuition: Assume I tell you a term has type forall a. a -> a, what could it be?

The only sensible term of this type is the function f defined as:

f x = x

Page 51: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory51

The Sky is the Limit!

The type system becomes a programming language of its own

Programs at the type level are proofs about the “regular” programs

Proof-Carrying Code: An emerging industry!

Page 52: Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى Indiana University

October 22, 2001 Design Patterns and Type Theory52

Conclusion

Abstraction is at the heart of CS

Finding the right abstractions is hard: engineering aspect of Programming

Expressing and enforcing rich abstractions: theoretical foundations of Programming Languages