Object Fundamentals Part Three. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 4 09/03/2009

Similar documents
Object Fundamentals Part Three. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 Lecture 4 09/06/2007

MORE OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 4 09/01/2011

More OO Fundamentals. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 4 09/11/2012

Lecture 2 and 3: Fundamental Object-Oriented Concepts Kenneth M. Anderson

Object Fundamentals Part Two. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 3 09/01/2009

UML & OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 3 08/30/2011

UML & OO Fundamentals. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 3 09/04/2012

COMP200 INTERFACES. OOP using Java, from slides by Shayan Javed

Object Oriented Programming Part II of II. Steve Ryder Session 8352 JSR Systems (JSR)

Object Fundamentals. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 Lecture 2 08/30/2007

Object Fundamentals, Part One. Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 2 08/27/2009

Java Session. Day 2. Reference: Head First Java

Object-Oriented ProgrammingInheritance & Polymorphism

Object-Oriented Programming More Inheritance

More on Design. CSCI 5828: Foundations of Software Engineering Lecture 23 Kenneth M. Anderson

Inf1-OP. Inheritance. Volker Seeker, adapting earlier version by Perdita Stevens and Ewan Klein. March 12, School of Informatics

Inheritance & Polymorphism. Object-Oriented Programming

Programmieren II. Polymorphism. Alexander Fraser. June 4, (Based on material from T. Bögel)

Inheritance & Polymorphism

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects

Inf1-OP. Classes with Stuff in Common. Inheritance. Volker Seeker, adapting earlier version by Perdita Stevens and Ewan Klein.

Software Development (cs2500)

Inf1-OOP. Inheritance and Interfaces. Ewan Klein, Perdita Stevens. January 12, School of Informatics

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming

Programming using C# LECTURE 07. Inheritance IS-A and HAS-A Relationships Overloading and Overriding Polymorphism

Credit where Credit is Due. Lecture 25: Refactoring. Goals for this lecture. Last Lecture

Pattern Resources. Lecture 25: Design Patterns. What are Patterns? Design Patterns. Pattern Languages of Programming. The Portland Pattern Repository

Encapsulation. Inf1-OOP. Getters and Setters. Encapsulation Again. Inheritance Encapsulation and Inheritance. The Object Superclass

References: Jacquie Barker,Beginning Java Objects; Martin Fowler,UML Distilled, 9/25/ UML

Inheritance. EEC 521: Software Engineering. Dealing with Change. Polymorphism. Software Design. Changing requirements Code needs to be flexible

Lecture 13: Design Patterns

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004

Inheritance, Polymorphism, and Interfaces

Object-Oriented Software Development Goal and Scope

Principles of Object-Oriented Design

Object- Oriented Design with UML and Java Part I: Fundamentals

Building custom components IAT351

Week 7. Statically-typed OO languages: C++ Closer look at subtyping

Expanding Our Horizons. CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 9 09/25/2011

Kerievsky_book.fm Page 355 Thursday, July 8, :12 PM. Index

CSC207 Week 3. Larry Zhang

C++ Programming: Introduction to C++ and OOP (Object Oriented Programming)

Using Design Patterns in Java Application Development

Inheritance and Polymorphism in Java

Object Oriented Programming. Michał Bereta

Relationships Between Real Things CSC 143. Common Relationship Patterns. Composition: "has a" CSC Employee. Supervisor

Agenda CS121/IS223. Reminder. Object Declaration, Creation, Assignment. What is Going On? Variables in Java

Computer Science II (20073) Week 1: Review and Inheritance

References: Jacquie Barker,Beginning Java Objects; Martin Fowler,UML Distilled, 1/13/ UML

Example: Count of Points

A Rapid Overview of UML

Relationships Between Real Things CSE 143. Common Relationship Patterns. Employee. Supervisor

CSA 1019 Imperative and OO Programming

PRINCIPLES OF SOFTWARE BIM209DESIGN AND DEVELOPMENT 00. WELCOME TO OBJECTVILLE. Speaking the Language of OO

CS121/IS223. Object Reference Variables. Dr Olly Gotel

Relationships Between Real Things. CSE 143 Java. Common Relationship Patterns. Composition: "has a" CSE143 Sp Student.

administrivia today UML start design patterns Tuesday, September 28, 2010

CS558 Programming Languages Winter 2013 Lecture 8

Inheritance and Substitution (Budd chapter 8, 10)

11/12/12. Objectives DESIGN PATTERNS. Design Pattern. Defined Design Patterns. Applying Design Patterns. Motivating Example

HAS-A Relationship. If A uses B, then it is an aggregation, stating that B exists independently from A.

Introduction to OO Concepts

Object-Oriented Concepts and Principles (Adapted from Dr. Osman Balci)

Programming Using C# QUEEN S UNIVERSITY BELFAST. Practical Week 7

Evolving Software. CMSC 433 Programming Language Technologies and Paradigms Spring Example. Some Motivations for This Refactoring

Inheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L

Originality is Overrated: OO Design Principles

Administrivia. Programming Language Fall Example. Evolving Software. Project 3 coming out Midterm October 28. Refactoring October 14, 2004

Object-Oriented Technology. Rick Mercer

Inheritance and Interfaces

Inheritance and Polymorphism

Dependency Injection. Kenneth M. Anderson University of Colorado, Boulder Lecture 30 CSCI 4448/ /08/11

Inheritance. Inheritance allows the following two changes in derived class: 1. add new members; 2. override existing (in base class) methods.

Superclasses / subclasses Inheritance in Java Overriding methods Abstract classes and methods Final classes and methods

Inheritance and Substitution גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

CSE1720. General Info Continuation of Chapter 9 Read Chapter 10 for next week. Second level Third level Fourth level Fifth level

COMP 250 Fall inheritance Nov. 17, 2017

Discussion. Type 08/12/2016. Language and Type. Type Checking Subtypes Type and Polymorphism Inheritance and Polymorphism

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Design Patterns. CSC207 Fall 2017

Introduction to Object-Oriented Programming

JAVA: A Primer. By: Amrita Rajagopal

ECE 122. Engineering Problem Solving with Java

CSCI-142 Exam 1 Review September 25, 2016 Presented by the RIT Computer Science Community

Java Fundamentals (II)

MechEng SE3 Lecture 7 Domain Modelling

FACADE & ADAPTER CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 7 09/13/2011

CSSE 220. Interfaces and Polymorphism. Check out Interfaces from SVN

More Relationships Between Classes

UML Primer. -Elango Sundaram

Advanced Object Oriented PHP

A Primer on Design Patterns

CSE 70 Final Exam Fall 2009

Inheritance and Substitution עזאם מרעי המחלקה למדעי המחשב אוניברסיטת בן-גוריון מובסס על הרצאות של אותו קורס שניתן בשנים הקודמות ע"י ד"ר גרא וייס

Exercise: Singleton 1

Outline. Java Models for variables Types and type checking, type safety Interpretation vs. compilation. Reasoning about code. CSCI 2600 Spring

Chapter 5 Object-Oriented Programming

Object Oriented Programming in Java. Jaanus Pöial, PhD Tallinn, Estonia

More About Objects. Zheng-Liang Lu Java Programming 255 / 282

Day 4. COMP1006/1406 Summer M. Jason Hinek Carleton University

Transcription:

Object Fundamentals Part Three Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 4 09/03/2009 1

Lecture Goals Continue our tour of the basic concepts, terminology, and notations for object-oriented analysis, design, and programming Some material for this lecture is drawn from Head First Java by Sierra & Bates, O'Reilly, 2003 2

Overview Delegation HAS-A Inheritance IS-A Interfaces Abstract Classes Object Identity Code Examples Polymorphism message passing polymorphic arguments and return types 3

Delegation (I) When designing a class, there are three ways to handle an incoming message Handle message by implementing code in a method Let the class s superclass handle the request via inheritance Pass the request to another object (delegation) Note: goes hand in hand with composition (not to be confused with aggregation/composition which is a design concept) You compose one object out of others The host object delegates requests to its internal objects 4

Delegation (II) Delegation is employed when some other class already exists to handle a request that might be made on the class being designed The host class simply creates a private instance of the helper class and sends messages to it when appropriate As such, delegation is often referred to as a HAS-A relationship A Car object HAS-A Engine object 5

Simple Example (I) Here is an example of a class delegating a responsibility to another class class GroceryList(object): def init (self, items): self.items = items def add_item(self, item): self.items.append(item) def print_items(self): for i, item in enumerate(self.items): print("{0}. {1}".format(i+1, item)) Grocery List has an attribute called items and it delegates all of its workrelated tasks (storing/enumerating items) to it. 6

Simple Example (II) We can create a GroceryList using a python list object like this: my_list = GroceryList([]) Now imagine, we no longer liked the capabilities of the default list and we wanted to switch to another class, for example, a list that keeps its items sorted my_list.items = SortedList(my_list.items) This line is creating a new sorted list, passing in the current set of items, and setting GroceryList.items to the new sorted list. This is an example of a delegation relationship changing at runtime. 7

Delegation (III) Advantages Delegation is dynamic (not static) delegation relationships can change at run-time Not tied to inheritance (indeed, considered much more flexible) In languages that support only single inheritance this is important! 8

Inheritance (I) Inheritance is a mechanism for sharing (public/protected) features between classes A class defines a type. A superclass is a more generic instance of that type. A subclass is a more specific instance of that type. A subtype typically restricts the legal values of its superclass Real Numbers Integers Positive Integers Component Container Control Button Checkbox 9

Inheritance (II) Subclasses have an IS-A relationship with their superclass A Hippo IS-A Animal makes sense while the reverse does not IS-A relationships are transitive If D is a subclass of C and C is a subclass of B, then D IS-A B is true Good OO design strives to make sure that all IS-A relationships in a software system make sense Consider Dog IS-A Canine vs. Dog IS-A Window The latter might actually be tried by an inexperienced designer who wants to display each Dog object in its own separate window This is known as implementation inheritance; it is considered poor design and something to be avoided 10

Inheritance (III) Inheritance enables significant code reuse since subclasses gain access to the code defined in their ancestors The next two slides show two ways of creating a set of classes modeling various types of Animals The first uses no inheritance and likely contains a lot of duplicated code The second uses inheritance and would likely require less code even though it has more classes than the former 11

Animals (No Inheritance) Lion makenoise() roam() sleep() Hippo makenoise() roam() sleep() Dog makenoise() roam() sleep() Cat makenoise() roam() sleep() Elephant makenoise() roam() sleep() Wolf makenoise() roam() sleep() Tiger makenoise() roam() sleep() Rhino makenoise() roam() sleep() 12

Animals (With Inheritance) Animal sleep() Pachyderm roam() Feline roam() Canine roam() Rhino makenoise() Wolf makenoise() Dog makenoise() Hippo makenoise() Tiger makenoise() Cat makenoise() Elephant makenoise() Lion makenoise() 13

Code Metrics Indeed, I coded these two examples and discovered without inheritance: 9 files, 200 lines of code with inheritance: 13 files, 167 lines of code approximately a 15% savings, even for this simple example 14

Inheritance (IV) An important aspect of inheritance is substitutability Since a subclass can exhibit all of the behavior of its superclass, it can be used anywhere an instance of its superclass is used The textbook describes this as polymorphism Furthermore, subclasses can add additional behaviors that make sense for it and override behaviors provided by the superclass, altering them to suit its needs This is both powerful AND dangerous Why? Stay tuned for the answer 15

Polymorphism (I) OO programming languages support polymorphism ( many forms ) In practice, this allows code to be written with respect to the root of an inheritance hierarchy and function correctly when applied to the root s subclasses 16

Polymorphism (II) Message Passing vs. Method Invocation With polymorphism, a message ostensibly sent to a superclass, may be handled by a subclass Compare this with this Animal a = new Animal() a.sleep() // sleep() in Animal called Animal a = new Lion() a.sleep() // sleep() in Lion called 17

Polymorphism Example Without polymorphism, the code on the right only calls methods in Animal Think C++ non-virtual method invocations With polymorphism a.roam() invokes Feline.roam() a.makenoise() invokes Lion.makeNoise() A message sent to Animal travels down the hierarchy looking for the most specific method body In actuality, method lookup starts with Lion and goes up Animal makenoise() roam() sleep() roam() Feline Lion makenoise() Animal a = new Lion() a.makenoise(); a.roam(); a.sleep(); 18

Why is this important? Polymorphism allows us to write very abstract code that is robust with respect to the creation of new subclasses For instance public void gotosleep(animal[] zoo) { for (int i = 0; i < zoo.length; i++) { zoo[i].sleep(); } } 19

Importance (II) In the previous code we don t care what type of animals are contained in the array we just call sleep() and get the correct behavior for each type of animal Indeed, if a new subclass of animal is created the above code still functions correctly AND it doesn t need to be recompiled with dynamic class loading, if the above code was running in a server, you wouldn t even need to stop the server ; you could simply load a new subclass and keep on trucking It only cares about Animal, not its subclasses as long as Animal doesn t change, the addition/removal of Animal subclasses has no impact 20

Importance (III) We can view a class s public methods as establishing a contract that it and its subclasses promise to keep if we code to the (root) contract, as we did in the previous example, we can create very robust and easy to maintain software systems This perspective is known as design by contract 21

Importance (IV) Earlier, we referred to method overloading as powerful AND dangerous The danger comes from the possibility that a subclass may change the behavior of a method such that it no longer follows the contract established by a superclass such a change will break previously abstract and robust code 22

Importance (V) Consider what would happen if an Animal subclass overrides the sleep() method to make its instances flee from a predator or eat a meal Our gotosleep() method would no longer succeed in putting all of the Zoo s animals to sleep If we could not change the offending subclass, we would have to modify the gotosleep() method to contain special case code to handle it this would break abstraction and seriously degrade the maintainability of that code Why? 23

Polymorphism (III) Finally, polymorphism is supported in arguments to methods and method return types In our gotosleep() method, we passed in a polymorphic argument, namely an array of Animals The code doesn t care if the array contains Animal instances or any of its subclasses 24

Polymorphism (IV) In addition, we can create methods that return polymorphic return values. For example public Animal createrandomanimal() { // code that randomly creates and // returns one of Animal's subclasses } When using the createrandomanimal() method, we don t know ahead of time which instance of an Animal subclass will be returned That s okay as long as we are happy to interact with it via the API provided by the Animal superclass 25

Abstract Classes/Interfaces There are times when you want to make the design by contract principle explicit Abstract classes and Interfaces let you do this An abstract class is simply one which cannot be directly instantiated It is designed from the start to be subclassed It does this by declaring a number of method signatures without providing method implementations for them this sets a contract that each subclass must meet 26

Abstract Classes, Continued Abstract classes are useful since they allow you to provide code for some methods (enabling code reuse) while still defining an abstract interface that subclasses must implement Zoo example Animal a = new Lion(); // manipulate Lion via Animal Animal a = new Animal(); // what Animal is this? Animal, Feline, Pachyderm, and Canine are good candidates for being abstract classes 27

Interfaces Interfaces go one step further and only allow the declaration of abstract methods you cannot provide method implementations for any of the methods declared by an interface Interfaces are useful when you want to define a role in your software system that could be played by any number of classes 28

Interface Example Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeforwalk()) We have several options, all with pros and cons add Pet-related methods to Animal add abstract Pet methods to Animal add Pet methods only in the classes they belong (no explicit contract) make a separate Pet superclass and have pets inherit from both Pet and Animal make a Pet interface and have only pets implement it This often makes the most sense although it hinders code reuse Variation: create Pet interface, but then create Pet helper class that is then composed internally and Pet s delegate if they want the default behavior 29

Object Identity In OO programming languages, all objects have a unique id This id might be its memory location or a unique integer assigned to it when it was created This id is used to enable a comparison of two variables to see if they point at the same object See example next slide 30

Identity Example public class identity { public static void compare(string a, String b) { if (a == b) { System.out.println("(" + a + ", " + b + "): identical"); } else if (a.equals(b)) { System.out.println("(" + a + ", " + b + "): equal"); } else { System.out.println("(" + a + ", " + b + "): not equal"); } } public static void main(string[] args) { String ken = "Ken Anderson"; String max = "Max Anderson"; compare(ken, max); ken = max; compare(ken, max); max = new String("Max Anderson"); compare(ken, max); } Not Equal Identical Equal } 31

Identity in OO A&D (I) Identity is also important in analysis and design We do not want to create a class for objects that do not have unique identity in our problem domain Consider people in an elevator Does the elevator care who pushes its buttons? Consider a cargo tracking application Does the system need to monitor every carrot that exists inside a bag? How about each bag of carrots in a crate? Consider a flight between Denver and Chicago What uniquely identifies that flight? The plane? The flight number? The cities? What? 32

Identity in OO A&D (II) When doing analysis, you will confront similar issues you will be searching for uniquely identifiable objects that help you solve your problem 33

Ken s Corner (I) Big names in OO circles (this list is dreadfully incomplete) Alan Kay: <http://en.wikipedia.org/wiki/alan_kay> Three Amigos One of the fathers of OO programming Grady Booch: <http://en.wikipedia.org/wiki/grady_booch> Co-inventor of UML; long time advocate of OO A&D Ivar Jacobson: <http://en.wikipedia.org/wiki/ivar_jacobson> Co-inventor of UML; wrote OO software engineering James Rumbaugh: <http://en.wikipedia.org/wiki/james_rumbaugh> Co-inventor of UML; developed Object Modeling Technique (OMT) Martin Fowler <http://www.martinfowler.com/> Prolific author on OO topics such as refactoring, patterns, UML, etc. 34

Ken s Corner (II) Big names in OO circles (this list is still dreadfully incomplete) Kent Beck: <http://en.wikipedia.org/wiki/kent_beck> Inventor of Extreme Programming; popularized test-driven design/junit Ward Cunningham: <http://en.wikipedia.org/wiki/ward_cunningham> Inventor of the wiki; long time advocate for design patterns Erich Gamma: <http://en.wikipedia.org/wiki/erich_gamma> Wrote Design Patterns with The Gang of Four (GoF) which also includes Richard Helm, Ralph Johnson, John Vlissides Many, many more for instance, the designers of OO languages: Alan Kay (Smalltalk), Bjarne Stroustrup (C++), Guido van Rossum (Python), Yukihiro Matsumoto Matz (Ruby), Anders Hejlsberg (C#), Brad Cox (Objective C), Brendan Eich (Javascript), Bertrand Meyer (Eiffel); See <http:// en.wikipedia.org/wiki/object-oriented_programming_language> for more! 35

Coming Up Next Lecture 5: Great Software Read Chapter 1 of the OO A&D book Lecture 6: Give Them What They Want Read Chapter 2 of the OO A&D book 36