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

2. “Object-oriented”--definition What does "Object Oriented" mean?

3. Problems of software development • "problems" of software development (review): • conceptual integrity • incremental build, progressive refinement • large projects "differ" from small ones

4. Languages and design methodology 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

5. OO class • 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”)

6. Record/class traditional: record (struc): functions to use or modify this record can be anywhere in the program OO: class concept supports encapsulation, information hiding OO Prog. DATA DATA DATA DATA DATA DATA DATA Procedural Prog.

7. Ex: Object data structures: A. Base class B. Derived class X Y Z W X Y Z A. B. Inheritance 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 animal animal 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 plant the 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

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

9. Templates 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

10. Separate compilation • 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

11. Design Patterns (1) • Design Patterns: • References: • 1. Gamma, Helm, Johnson, and Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. • Deitel, Appendix M. • 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

12. Design Patterns (2) • 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

13. Design Patterns (3) • 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

14. Design Patterns (4) • 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

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)

16. Misuse of object-oriented paradigm Note: no paradigm is misuse-proof

17. Using OO in project Using OO in project: we will use UML (subset) determine specifications: use cases determine classes and connections: ER diagrams CRC cards we need to handle both static and dynamic behavior: object message diagrams state diagrams sequence diagrams

18. Metrics for OO project 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?