Object-oriented paradigm

18
1 Brief Review of the Object- oriented Paradigm, Object- oriented Analysis and Design Object-oriented paradigm

description

Object-oriented paradigm. Brief Review of the Object-oriented Paradigm, Object-oriented Analysis and Design. “Object-oriented”--definition. What does "Object Oriented" mean?. Problems of software development. "problems" of software development (review): conceptual integrity - PowerPoint PPT Presentation

Transcript of Object-oriented paradigm

Page 1: Object-oriented paradigm

1

Brief Review of the Object-oriented Paradigm, Object-oriented Analysis and

Design

Object-oriented paradigm

Page 2: Object-oriented paradigm

2

What does "Object Oriented" mean?

“Object-oriented”--definition

Page 3: Object-oriented paradigm

3

"problems" of software development (review):

conceptual integrity

incremental build, progressive refinement

large projects "differ" from small ones

Problems of software development

Page 4: Object-oriented paradigm

4

Computer Language / Design Methodology: brief history:

1950's:unstructured, no information hiding--”spaghetti” code, GOTO, flowcharts--machine code--assembly lang. --FORTRAN, LISP(Algol; COBOL)

1980’s: structured, top-down design (“3 basic control structures, no GOTO”), modularity--Pascal--(C)--Ada

1990’s: encapsulation, information-hiding, reuse, hardware/software codesign

--C++--Java

2000’s: info hiding; web languages; environments encapsulating multiple languages--.NET--Python

Languages and design methodology

Page 5: Object-oriented paradigm

5

Important basic OO concepts:

class: encapsulates data structure (object) and associated methods (functions) these may be declared public / private / protected

appropriate uses:

public: pass info to object or request info about object(use "messages") (can be used by anyone)

private: modify object (can be used in class or by “friends”)

protected: for descendants (in class or by derived class and “friends”)

OO class

Page 6: Object-oriented paradigm

6

traditional: record (struc): functions to use or modify this record can be anywhere in the program

OO: class concept supports encapsulation, information hiding

Record/class

DATA

DATA

DATA

DATA

DATA

DATA

DATA

Procedural Prog.

OO Prog.

Page 7: Object-oriented paradigm

7

Useful OO techniques:

Inheritance:ex: in a program modeling an ecosystem, we might have the relationships:

wolf is carnivore; sheep is herbivore; grass is plant carnivore is animal; herbivore is animalanimal is organism; plant is organism

here the base class “organism” holds data fields which apply to all organisms, e.g., amount of water needed to survive two derived classes, plant and animal, hold information specific to each of these types of organisms, e.g., kind of soil preferred by plantthe animal class also has two derived classes, wolf and sheep

Inheritance allows the collection of common attributes and methods in "base" class and inclusion of more specific attributes and methods in derived classes

Inheritance

A. B.Ex: Object data

structures:

A. Base class

B. Derived class

X

Y

Z

X

Y

Z

W

Page 8: Object-oriented paradigm

8

Polymorphism:

base class can define a “virtual” function; appropriate versions of this function can be instantiated in each derived class (e.g., "draw" in the base class of graphical objects can have its own specific meaning for rectangles, lines, ellipses)

Overloading:

ex: cin >> num1;>> is overloaded "shift”

ex: “+” can be overloaded to allow the addition of two vectors

ex: a function name can be overloaded to apply to more than one situation; e.g., a constructor can be defined one way if initial values are given and a different way if initial values are not given

Polymorphism and overloading

Page 9: Object-oriented paradigm

9

Templates:

example:

template <class T> T method1 (T x) …..

can be specialized: int method1 (int x)

float method1 (float y)

usertype method1 (usertype a)

templates promote reuse

Templates

Page 10: Object-oriented paradigm

10

Separate compilation:

Typically, an object-oriented program can be broken into three sets of components:

definitions and prototypes (text files, “header files”)

implementations (compiled--source code need not be available to user)

application program--uses the classes defined in header files and supported by the implementation files

This strategy promotes reuse and information hiding

Separate compilation

Page 11: Object-oriented paradigm

11

Design Patterns:

References: 1. Gamma, Helm, Johnson, and Vlissides, Design Patterns,

Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

2. Deitel, Appendix M.3. Tutorial by James Cooper (link on schedule page).

useful for experienced oo programmers--”what worked well in the past” for common oo programming problems

many examples of design patterns can be found in the literature and on the web

Design Patterns (1)

Page 12: Object-oriented paradigm

12

3 basic types of design patterns are usually defined:

•creational--common methods for constructing objects

•structural--common ways of resolving questions about interobject relationships

•behavioral--common ways of dealing with object behavior that depends on context

Design Patterns (2)

Page 13: Object-oriented paradigm

13

Some common creational design patterns:

•abstract factory--creates a set of related objects

•builder--keeps details of data conversions, if different data types supported

•factory method--defines interface for creating a method, rather than a specific method

•prototype--gives prototypical instance for object creation

•singleton--ensures that only one instance of class is created; provides global access point

Design Patterns (3)

Page 14: Object-oriented paradigm

14

Some common structural design patterns:

•adapter--translates between interacting objects with incompatibilities

•bridge--flexible method for implementing multiple instances of abstract class

•composite--hierarchical grouping of different numbers of objects from varying classes

•decorator--wrapper around original object, with additional dynamic features

•façade--standard front end for a series of classes

•flyweight--allows sharing to support many fine-grained objects efficiently

•proxy--delays the instantiation of the class until the object is needed

Design Patterns (4)

Page 15: Object-oriented paradigm

15

Some common behavioral design patterns:

•chain of responsibility--give objects in a chain of objects a chance to handle a request

•command--encapsulate request as parameterized object; allow undoable commands

•interpreter--define a method for each rule in a given grammar

•iterator--access elements of an aggregate object, keeping representation private

•mediator--holds explicit object references for classes that would otherwise be highly coupled

•memento--store an object state for checkpoints or rollbacks

•observer--all instances will be notified of changes to the observed class

•state--behavior of an object can depend on the state it is in

•strategy--set of related algorithms for a certain problem

•template method--details of the algorithm are left to subclasses

•visitor--allow new operations to be defined on an object structure without changing classes on which they operate

Design Patterns (5)

Page 16: Object-oriented paradigm

16

Note: no paradigm is misuse-proof

Misuse of object-oriented paradigm

Page 17: Object-oriented paradigm

17

Using OO in project: we will use UML (subset)

determine specifications:use cases

determine classes and connections: ER diagramsCRC cards

we need to handle both static and dynamic behavior:object message diagramsstate diagramssequence diagrams

Using OO in project

Page 18: Object-oriented paradigm

18

Metrics for size / difficulty of an OO project:can count number of use cases, number of classes

(key/support), number of "subsystems" (groups of classes); also LOC, bugs identified and fixed

How do you start an OO design?--components?--objects?--how will they interact?

Metrics for OO project