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

3ָ�

ןנ

Why Teaching Design is Interesting?

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