Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى...
-
Upload
marcia-hines -
Category
Documents
-
view
215 -
download
0
Transcript of Program Design, Design Patterns, Type Theory, and other buzzwords. Amr Sabry عمرو صبرى...
Program Design,Design Patterns,
Type Theory,and other buzzwords.
Amr Sabry
صبرى عمروIndiana University
October 22, 2001 Design Patterns and Type Theory2
Playing Music
October 22, 2001 Design Patterns and Type Theory3
Building Structures
October 22, 2001 Design Patterns and Type Theory4
Programming
(define fact
(lambda (n)
(if (zero? n)
1
(* n (fact (sub1 n))))))
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.
October 22, 2001 Design Patterns and Type Theory6
Outline
Part I
Abstraction and Reuse
Part II
Abstraction and Safety
Part I
Abstraction and Reuse
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!!!
October 22, 2001 Design Patterns and Type Theory9
Which is an abstraction of a human?
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!
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)
October 22, 2001 Design Patterns and Type Theory12
Warning!
Lots of details to follow!
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.
October 22, 2001 Design Patterns and Type Theory14
An Initial Java Design
FoodItem
IceCream Hotdog Pizza
CostPrice
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; }}
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; }}
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!
October 22, 2001 Design Patterns and Type Theory18
Updated Design
FoodItem
IceCream Hotdog Pizza
CostPrice
Vegetables
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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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!
October 22, 2001 Design Patterns and Type Theory21
Updated Design
FoodItem
IceCream Hotdog Pizza
CostPriceCalories
Vegetables
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…
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.
October 22, 2001 Design Patterns and Type Theory24
Visitor Pattern
FoodItem
IceCream Hotdog Pizza
acceptVegetables
FoodVis
CostVis PriceVis CaloriesVis
visitIceCreamvisitHotDogvisitPizzavisitVegetables
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; } …}
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.
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.
Part II
Abstraction and Safety
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?
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
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);}
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.
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!!!
October 22, 2001 Design Patterns and Type Theory34
Warning!
Lots of details to follow!
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 };
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);
}
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
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
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.
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
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
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)
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
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
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
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
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)))
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
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
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
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!
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