Upload
felicity-west
View
216
Download
3
Embed Size (px)
Citation preview
oop
1ָ�
ןנ
Teaching vsTeaching vs. . Learning Learning Software DesignSoftware Design
Witch Doctors inWitch Doctors inSoftware EngineeringSoftware Engineering
sd
2ָ�
ןנ
Why not Teach Design?
Software design courses have probably created more bad designers and software disasters than any stupidity and malice combined!
sd
4ָ�
ןנ
Why is Writing Software Difficult? Programs are just like mathematical proofs:
Cannot be produced automatically. Intuition can be misleading. Failure in any step may cause the whole edifice to collapse.
Proofs more difficult: Higher level of abstraction and ingenuity.
Simplicity can be misleading. Proofs are rarely redone.
Programs more difficult:Proofs are shorter.
• A modest program is equivalent in size to the classification of simple groups to the proof of Fermat’s last theorem.
Programs are misleadingly simple.Programs may not contain typos.Programs are not done by first class mathematicians.Demand for programs is much higher than demand for proofs.
sd
5ָ�
ןנ
SE and Other Disciplines of Science
Planets Particles Economy People Software
Experiments - + - +- -
Measurements +(limited)
+-(changebehaviour)
+ +- -
Few SimpleRules
+ + +- - -
HumanPhenomena
- - - + +
sd
6ָ�
ןנ
SE and Medicine
Many complex rules No experiments Measurements are not easy Witch doctors Other disciplines’ witch doctors:
Alchemists Astrologists European school of economics Advice books
sd
7ָ�
ןנ
The First Principle of Witch Doctoring
We are all in the gutter, but some of us are looking at the stars.
Oscar Wilde, from Lady Windermere's Fan
sd
8ָ�
ןנ
“Behaviour of an object - how an object acts and reacts, in terms of its state changes and message passing.”
[G. Booch, OODwA, '91, p. 80]
“Operation -- some action that one object performs upon another in order to elicit a reaction.”
[G. Booch, OODwA, '91, p. 80]
The terms operation and message are interchangeable.
“Method -- operation that a client may perform upon an object.”
[G. Booch, OODwA, '91, p. 80]
Formal Definitions
sd
9ָ�
ןנ
Abstraction Abstraction: find commonality of several phenomena
Good abstraction: Ignore the “irrelevant” details Find the “relevant” commonalities Maximize “relevant” commonalities
Abstractions are almost invariably relative to a domain of interest
Phenomenon A Phenomenon B
Phenomenon C
SomeAbstraction
Phenomenon 1 Phenomenon 2
Phenomenon 3
AnotherAbstraction
sd
10ָ�
ןנ
Abstraction is Relative to Domain
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer.
sd
11ָ�
ןנ
Abstract at the Right Level
Classes and objects should be at the right level of abstraction: neither too high nor too low.
sd
12ָ�
ןנ
An IQ Test
Table and Chair? Cat and Dog? Dog and Wolf? Pencil and Cup? School and Bank? Decline and wriggle? Jewels and Apartment? Salary raise and court-of-law? Army and clothings? Aesophagus and genealogy?
What’s in common to:
sd
13ָ�
ןנ
Abstraction and ReusabilityBenefits:
Reduce development cost:
one component instead of many Promote reliability:
exercise component from many different aspectsno need to remember to correct the same error twice
Software Component
Client 1 Client 2
sd
14ָ�
ןנ
The Principle of Little Numbers
0 > 1: What you don't know cannot hurt you. Information hiding, encapsulation, table driven programming, modularity, etc.
1 > 2: If the same thing occurs twice in the code, then it occurs one time too many.
Software is constantly subject to change. As changes occur, maintaining the two almost identical parts will become a nightmare.
For (ever) {Write Code;While (exist(similar parts)) {
Extract identical portion;Rewrite code;
}}
sd
15ָ�
ןנ
Redundancy is Redundant! Applying the above algorithm:
Code: procedures and functions, libraries, macros, software reusability, code sharing, ...
Comments: "Don't repeat the code in your comments", ...
Text: "Don't prepare the table of contents manually", ...
Data (Non-OOP): typedef, void *, generic functions (e.g., qsort), variable arguments (e.g., printf), macros (e.g., #define SIZEOF(a) (sizeof(a)/sizeof(a[0]))), etc.
Data (OOP): Extract the common parts of two different data-types and put these in a super-class.
Inheritance
sd
16ָ�
ןנ
Redundancy is Redundant! Applying the above algorithm:
code procedures and functions, libraries, macros, software reusability, code sharing, ...
comments "Don't repeat the code in your comments", ...
text "Don't prepare the table of contents manually", ...
data Non-OOP: typedef, void *, generic functions (e.g., qsort), variable arguments (e.g., printf), macros (e.g., #define SIZEOF(a) (sizeof(a)/sizeof(a[0]))), etc.
data: OOP. Extract the common parts of two different data-types and put these in a super-class.
Inheritance
sd
17ָ�
ןנ
Taxonomy
Abstraction ofAbstractions
Phenomenon 1 Phenomenon 2
Phenomenon 3
An Abstraction
Phenomenon A Phenomenon B
Phenomenon C
AnotherAbstraction
TAXONOMY
Taxonomy: Abstraction of Abstractions
tax·on·o·my (t²k-s¼n“…-m¶) n., pl. tax·on·o·mies. 1. The classification of organisms in an ordered system that indicates natural relationships. 2. The science, laws, or principles of classification; systematics. 3. Division into ordered groups or categories: “Scholars have been laboring to develop a taxonomy of young killers” (Aric Press). [French taxonomie : Greek taxis, arrangement; see TAXIS + -nomie, method (from Greek -nomia; see -NOMY).] --tax·on“o·mist n.
sd
18ָ�
ןנ
Successful Taxonomies:
Taxonomy: the ultimate goal of the abstraction process Examples:
Linguistic: classification of languages. Biology: kingdom, phylum, subphylum, class, order, family,
genus, species. Chemistry: the periodic table of the elements. Mathematics: Algebraic structure - group, ring, commutative-
ring, skewed-field, field, algebra, ... Computer Science: Kinds of polymporphism.
sd
19ָ�
ןנ
Program Domain TaxonomyDescartes: “the discovery of an order is no easy task ... yet once the order has been discovered there is no difficulty at all in knowing it.”
Evidently, no “right order” was found for the classification of data structures, or even the basic data types. There are just too many of them out there.
Set
L ist
S tring
ByteArray
Array D ictionary
IndexedC ollection
Interva l
C ollection
Bag
LinkedList
Array S tring ByteArray
ArrayedC ollection Interval
SequenceableC ollection
D ictionary
Set
C ollection
Smalltalk-80 Little Smalltalk v 3.0
sd
20ָ�
ןנ
Lingual Abstraction Mechanisms Procedure call:
as in structure programming. Modules:
as in modular programming. Abstract data types:
as in object-based programming:Export type definition + set of operationsProtect data. Instantiation.
Composition: Similarity between components of abstract data types.
Inheritance Classification of ADTs. Similarity between abstract data types.
Dynamic Binding: Actual representation independence.
Genericity Similarity between operations on different types.
sd
21ָ�
ןנ
Meta-Abstraction Abstraction of the abstraction process:
Recipes for finding the “right” abstractions.
Tends to be: trivial, vague, or both!
Phenomenon A Phenomenon B
Phenomenon C
Yet Another UsefulAbstraction
Phenomenon 1 Phenomenon 2
Phenomenon 3
Some UsefulAbstraction
MetaAbstraction
sd
22ָ�
ןנ
“Object Oriented Analysis” OOA:
Given a problem domain, Decide on the correct set of abstractions
Activities: Identify classes ( and “objects”?) in the problem domain.
Discover classes. Invent generalizations.
• Abstract classes
Methods of OOA: Recipes, heuristics, techniques, ideas, which should help you to do OOA.
Abstract over the abstraction process in the problem domain.
Meta abstraction tends to be: Trivial Vague Both
sd
23ָ�
ןנ
Real Class Hierarchy
Fundamental User Defined
ClassEnumeratedPrimitive Compound
Address
Pointer Reference
is_constis_volatile
Type
Sizeis_signed
Integer
Size
Real Void Function
SizeArray
sd
24ָ�
ןנ
Meta-Meta AbstractionOrganize the activities involved in meta-abstractions.
Work on the “software process”
Capability maturity model
Life cycle models
Waterfall model Spiral model Cluster model
sd
25ָ�
ןנ
Real Techniques Language Level:
Abstraction mechanisms
Evangelist Level: Style guidelines and rules
Code level Static strong typing: subtypes, polymorphism, const correctness, genericity,
constrained genericity.A program will never make a type error.
Testing and code metrics. Formal verification
Run time level: Garbage collection:
A program will never access an invalid address in memory, nor will it create memory leaks.
Assertions: pre-conditions, post conditions, loop invariants, loop variants, loop variants, class invariants, check points.
A program will not proceed if it violates certain design decisions.
sd
26ָ�
ןנ
Teaching Design We cannot
Teach you how to design Make you smart Force you to think Make you paranoid Make you pedantic Remake you
We can teach Some good designs made by others Some tricks of the trade Trivial rules
We can force you To practice design To abide by our subjective criteria
We can hope That you will grow to be a good designer