ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Issues.

Slides:



Advertisements
Similar presentations
Chapter 13 Abstraction and inheritance. This chapter discusses n Implementing abstraction. u extension u inheritance n Polymorphism/dynamic binding. n.
Advertisements

More on Classes Inheritance and Polymorphism
Chapter 1 Object-Oriented Concepts. A class consists of variables called fields together with functions called methods that act on those fields.
Module 8 “Polymorphism and Inheritance”. Outline Understanding Inheritance Inheritance Diagrams Constructors in Derived Classes Type Compatibility Polymorphism.
CS 2430 Day 28. Announcements Program 5 was posted (on Tuesday, 4/2/2013) Can work with a partner (sign up by today at 3:52pm) Exam 2 handed back on Monday.
Intro to OOP with Java, C. Thomas Wu Inheritance and Polymorphism
Creating Classes from Other Classes Chapter 2 Slides by Steve Armstrong LeTourneau University Longview, TX  2007,  Prentice Hall.
Overview of Java (continue). Announcements You should have access to your repositories and HW0 If you have problems getting HW0, let me know If you’ve.
1 Chapter 6 Inheritance, Interfaces, and Abstract Classes.
Introduction to Inheritance Fall 2005 OOPD John Anthony.
CSCI-383 Object-Oriented Programming & Design Lecture 15.
Abstract classes and Interfaces. Abstract classes.
Unit 5 School of Information Systems & Technology1 School of Information Systems and Technology (IST)
1 Inheritance and Polymorphism Chapter 9. 2 Polymorphism, Dynamic Binding and Generic Programming public class Test { public static void main(String[]
Object-oriented metrics Design decisions: Class Cohesion Open-Closed Single Responsibility Interface Segregation Dependency Inversion Liskov Substitution.
CSM-Java Programming-I Spring,2005 Objects and Classes Overview Lesson - 1.
CSE 332: C++ templates This Week C++ Templates –Another form of polymorphism (interface based) –Let you plug different types into reusable code Assigned.
CSC 142 O 1 CSC 142 Java More About Inheritance & Interfaces [Reading: chapter 13]
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
1 Object-Oriented Software Engineering CS Interfaces Interfaces are contracts Contracts between software groups Defines how software interacts with.
Features of Object Oriented Programming Lec.4. ABSTRACTION AND ENCAPSULATION Computer programs can be very complex, perhaps the most complicated artifact.
CMSC 202 Generics. Nov Generalized Code One goal of OOP is to provide the ability to write reusable, generalized code. Polymorphic code using.
Lecture 8: Object-Oriented Design. 8-2 MicrosoftIntroducing CS using.NETJ# in Visual Studio.NET Objectives “Good object-oriented programming is really.
CSE 301 Exam Revision Lecture
Inheritance in the Java programming language J. W. Rider.
1 Abstract Classes “I prefer Agassiz in the abstract, rather than in the concrete.” CS Computer Science II.
Java 5 Part 1 CSE301 University of Sunderland Harry Erwin, PhD.
1 final (the keyword, not the exam). 2 Motivation Suppose we’ve defined an Employee class, and we don’t want someone to come along and muck it up  E.g.,
Object Oriented Software Development
Factory Method Explained. Intent  Define an interface for creating an object, but let subclasses decide which class to instantiate.  Factory Method.
Chapter FifteenModern Programming Languages1 A Second Look At Java.
Inheritance. Inheritance - Introduction Idea behind is to create new classes that are built on existing classes – you reuse the methods and fields and.
Object Oriented Programming
Design Patterns Introduction
Inheritance CSI 1101 Nour El Kadri. OOP  We have seen that object-oriented programming (OOP) helps organizing and maintaining large software systems.
Application development with Java Lecture 21. Inheritance Subclasses Overriding Object class.
 In the java programming language, a keyword is one of 50 reserved words which have a predefined meaning in the language; because of this,
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
JAVA Programming (Session 4) “When you are willing to make sacrifices for a great cause, you will never be alone.” Instructor: รัฐภูมิ เถื่อนถนอม
1 Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 9.1 – 9.4.
Inheritance Type/Subtype Relationship. Inheritance Idea: An object B of one type, termed child class, inherits from another object A of another type,
Quick Review of OOP Constructs Classes:  Data types for structured data and behavior  fields and methods Objects:  Variables whose data type is a class.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
Design Patterns. Outline Purpose Purpose Useful Definitions Useful Definitions Pattern Overview Pattern Overview.
Terms and Rules II Professor Evan Korth New York University (All rights reserved)
Unified Modeling Language (UML)
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
CSC 243 – Java Programming, Spring, 2014 Week 4, Interfaces, Derived Classes, and Abstract Classes.
9.1 CLASS (STATIC) VARIABLES AND METHODS Defining classes is only one aspect of object-oriented programming. The real power of object-oriented programming.
Classes CS 162 (Summer 2009). Parts of a Class Instance Fields Methods.
CSC 243 – Java Programming, Fall, 2008 Tuesday, September 30, end of week 5, Interfaces, Derived Classes, and Abstract Classes.
CSCI 383 Object-Oriented Programming & Design Lecture 15 Martin van Bommel.
Comp1004: Object Oriented Design I Abstract Classes and Interfaces.
More About Java and Java How to Program By Deitel & Deitel.
Sections Inheritance and Abstract Classes
Inheritance and Polymorphism
CSE 331 Subtyping slides created by Marty Stepp based on materials by M. Ernst, S. Reges, D. Notkin, R. Mercer, Wikipedia
Section 11.1 Class Variables and Methods
Object Oriented Practices
Inheritance, Polymorphism, and Interfaces. Oh My
Week 6 Object-Oriented Programming (2): Polymorphism
Subtype Polymorphism, Subtyping vs
Topic 10 Abstract Classes “I prefer Agassiz in the abstract,
Topic 10 Abstract Classes “I prefer Agassiz in the abstract,
COMPUTER 2430 Object Oriented Programming and Data Structures I
Chapter 9 Carrano Chapter 10 Small Java
CIS 199 Final Review.
Chapter 11 Inheritance and Polymorphism Part 2
Jim Fawcett CSE687 – Object Oriented Design Spring 2014
CIS 110: Introduction to computer programming
Presentation transcript:

ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Issues

ECE450 - Software Engineering II2 What’s wrong with this? public class PizzaMaker { public void cookPizzas(List pizzas) { for (int i=0; i<pizzas.size(); ++i) { Object pizza = pizzas.get(i); if (pizza instanceof ThinCrustPizza) { ((ThinCrustPizza)pizza).cookInWoodFireOven(); } else if (pizza instanceof PanPizza) { ((PanPizza)pizza).cookInGreasyPan(); } else { // OH NO! What is this thing? }

ECE450 - Software Engineering II3 The Open-Closed Principle Classes should be open for extension, but closed for modification –You should be able to extend a system without modifying the existing code The type-switch in the example violates this –Have to edit the code every time the marketing department comes up with a new kind of pizza

ECE450 - Software Engineering II4 Abstraction is the solution Solve the problem by creating a Pizza interface with a cook method –Or an abstract base class whose cook method must be overridden by every child The Template Method design pattern is used to set up the skeleton of an algorithm –Details then filled in by concrete subclasses

ECE450 - Software Engineering II5 Cooking a generic pizza public abstract class Pizza { public final void cook() { placeOnCookingSurface(); placeInCookingDevice(); int cookTime = getCookTime(); letItCook(cookTime); removeFromCookingDevice(); } protected abstract void placeOnCookingSurface(); protected abstract void placeInCookingDevice(); protected abstract int getCookTime(); protected abstract void letItCook(int min); protected abstract void removeFromCookingDevice(); }

ECE450 - Software Engineering II6 Is this general enough? But what if someone wants to do something you didn’t anticipate? –E.g. wants to add a PancakePizza that has to be flipped over halfway through the cooking process What are the options?

ECE450 - Software Engineering II7 Override the Template Method? But cook was final And it’s storing up trouble for the future public final void cook() { placeOnCookingSurface(); placeInCookingDevice(); int cookTime = getCookTime(); letItCook(cookTime/2); flip(); letItCook(cookTime/2); removeFromCookingDevice(); }

ECE450 - Software Engineering II8 Squeeze it somewhere else? removeFromCookingDevice shouldn’t be doing other things –Think about the documentation Once again, we’re storing up trouble for the future protected void removeFromCookingDevice() { flip(); letItCook(cookTime); …remove from skillet… }

ECE450 - Software Engineering II9 Leave space for future growth? public final void cook() { beforePlacingOnCookingSurface(); placeOnCookingSurface(); beforePlacingInCookingDevice(); placeInCookingDevice(); beforeCooking(); for (int i=0; i<getCookingPhases(); i++) { letItCook(getCookTime(i)); afterCookingPhase(i); } beforeRemovingFromCookingDevice(); removeFromCookingDevice(); afterRemovingFromCookingDevice(); }

ECE450 - Software Engineering II10 And the answer is... Plan for reasonable future growth –“Reasonable” means “guided by your experience, and the experience of others” Note: compliance with the Open-Closed principle is a matter of judgment –No algorithm or code analyzer can make a definitive ruling

ECE450 - Software Engineering II11 Liskov substitution principle Anywhere you specify a base type, you should be able to use an instance of a derived type –This one is checkable, if you provide the system with enough information Polymorphism that obeys the rules of Design by Contract –Allowed to weaken preconditions and strengthen postconditions, but not viceversa

ECE450 - Software Engineering II12 Is Vegan Pizza really pizza? public interface Pizza { public Cheese getCheese(); } public class SimplePizza implements Pizza { public Cheese getCheese() { return new Mozzarella(); } public class VeganPizza implements Pizza { public Cheese getCheese() { return null; }

ECE450 - Software Engineering II13 But then... Returning null violates the contract The problem is, that contract was implicit –Which is why languages like Ada allow programmers to make contracts explicit class Customer { public boolean decideToBuy(Pizza p) { Cheese c = p.getCheese(); return c.smellsGood(); }

ECE450 - Software Engineering II14 This is not a solution! Why is this bad? class Customer { public boolean decideToBuy(Pizza p) { Cheese c = p.getCheese(); if (c != null) { return c.smellsGood(); } else { return false; }

ECE450 - Software Engineering II15 Possible solutions Weaken or remove the supertype contract –Only if you have a strategy for updating existing code –Remember, the contract was there for a reason... Remove or replace the operation –Add a smellsGood method to pizza

ECE450 - Software Engineering II16 Possible solutions (cont) Modify the inheritance hierarchy –Only works if the code that calls getCheese knows if it has a real pizza or a vegan pizza «interface» Pizza «interface» CheesePizza SimplePizza VeganPizza

ECE450 - Software Engineering II17 Possible solutions (cont) Modify subtype behaviour –In this case, use the Null Object Pattern to return an instance of NullCheese Null Object Pattern: Having a non-null object whose job is to take the place of null, and whose methods all return 0, null, not-interesting, empty string, etc. A bit of a hack Opinions?

ECE450 - Software Engineering II18 It’s not my job Single Responsibility Principle: A class or interface should only be responsible for one thing –Alternative phrasing: A class or interface should have only one reason to change Count responsibilities: public interface Pizza { public List getToppings(); public void setToppings(List tops); public PizzaSize getSize(); public void setSize(PizzaSize size); public PizzaCrust getCrust(); public void setCrust(PizzaCrust crust); pub void cook(int temp, int minutes); public TasteRating rateTaste(); public SmellRating rateSmell(); public boolean isBurnt(); } building cooking

ECE450 - Software Engineering II19 Law of Demeter A method M of an object O may only invoke methods of: –Itself –Its parameters –Objects it creates –Its members In particular, methods should not invoke methods of other objects’ members A violation: This method depends on Pizza having a Cheese member, and Cheese having a smellsGood method –All these things might change. –The more indirect connections the code has, the harder it is to understand, test, and change public boolean buyPizza(Pizza p) { return p.getCheese().smellsGood(); }