Object-Oriented programming 1 SSD3: Object-Oriented Programming and Design.
Object Oriented Design
-
Upload
aravinth-nsp -
Category
Technology
-
view
2.834 -
download
1
description
Transcript of Object Oriented Design
![Page 1: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/1.jpg)
Object Oriented Design
Sudarsun S., M.TechDirector – R & D
Checktronix India Pvt Ltd
Chennai 600010
![Page 2: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/2.jpg)
OO Design - Sudarsun S 2
Objectives To explain how a software design may be
represented as a set of interacting objects that manage their own state and operations
To introduce various models that describe an object-oriented design
To introduce design patterns
![Page 3: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/3.jpg)
OO Design - Sudarsun S 3
What is an OBJECT
An instance of a CLASS Contains meaningful data Concepts that occupy memory space at
runtime are, according to the definition, objects If not, they are CLASSESFor example: data type vs. double
![Page 4: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/4.jpg)
OO Design - Sudarsun S 4
A little Quiz…
#1 Class or Object?Dog
Scooby-Doo
Dog is a generalization of Scooby-Doo
![Page 5: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/5.jpg)
OO Design - Sudarsun S 5
A little Quiz (cont’d)…
#2 Class or Object?Dog
Scooby-Doo
Animal
The concept of subclass!
Dog is a subclass of the Animal class
Animal is a generalization of Dog
![Page 6: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/6.jpg)
OO Design - Sudarsun S 6
A little Quiz (cont’d)… #3 Class or Object?
Animal
DogBird
The concept of polymorphism!
![Page 7: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/7.jpg)
OO Design - Sudarsun S 7
Characteristics of OOD Objects are abstractions of real-world or system
entities and manage themselves Objects are independent and encapsulate state and
representation information. System functionality is expressed in terms of object
services Shared data areas are eliminated
Objects communicate by message passing Objects may be distributed Objects may execute sequentially or in parallel
![Page 8: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/8.jpg)
OO Design - Sudarsun S 8
Interacting objects
state o3
o3:C3
state o4
o4: C4
state o1
o1: C1
state o6
o6: C1
state o5
o5:C5
state o2
o2: C3
ops1() ops3 () ops4 ()
ops3 () ops1 () ops5 ()
![Page 9: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/9.jpg)
OO Design - Sudarsun S 9
Advantages of OOD Easier maintenance. Objects may be
understood as stand-alone entities Objects are appropriate reusable
components For some systems, there may be an
obvious mapping from real world entities to system objects
![Page 10: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/10.jpg)
OO Design - Sudarsun S 10
Object-oriented development Object-oriented analysis, design and programming
are related but distinct OOA is concerned with developing an object model
of the application domain OOD is concerned with developing an object-
oriented system model to implement requirements OOP is concerned with realising an OOD using an
OO programming language such as Java or C++
![Page 11: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/11.jpg)
OO Design - Sudarsun S 11
Objects and object classes
Objects are entities in a software system which represent instances of real-world and system entities
Object classes are templates for objects Classes may be used to
create objects
Object classes may inherit attributes and services from other object classes
Employee
name: stringaddress: stringdateOfBirth: DateemployeeNo: integersocialSecurityNo: stringdepartment: Deptmanager: Employeesalary: integerstatus: {current, left, retired}taxCode: integer. . .
join ()leave ()retire ()changeDetails ()
![Page 12: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/12.jpg)
OO Design - Sudarsun S 12
Object communication Conceptually, objects communicate by message passing Messages
The name of the service requested by the calling object. Copies of the information required to execute the service
and the name of a holder for the result of the service.
In practice, messages are often implemented by procedure (a.k.a. method) calls Name = method name Information = parameter list Result holder = method return value
![Page 13: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/13.jpg)
OO Design - Sudarsun S 13
Message examples
// Call a method associated with a buffer // object that returns the next value // in the buffer
v = circularBuffer.Get() ;
// Call the method associated with a// thermostat object that sets the // temperature to be maintained
thermostat.setTemp(20) ;
![Page 14: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/14.jpg)
OO Design - Sudarsun S 14
Generalisation and inheritance Objects are members of classes which define attribute
types and operations Classes may be arranged in a class hierarchy where
one class (a super-class) is a generalisation of one or more other classes (sub-classes)
A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own
It is a reuse mechanism at both the design and the programming level
Inheritance introduces complexity and this is undesirable, especially in critical systems
![Page 15: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/15.jpg)
OO Design - Sudarsun S 15
A generalisation hierarchyEmployee
Programmer
projectprogLanguage
Manager
ProjectManager
budgetsControlled
dateAppointed
projects
Dept.Manager
StrategicManager
dept responsibilities
![Page 16: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/16.jpg)
OO Design - Sudarsun S 16
Object Relationships Objects and object classes participate in relationships with
other objects and object classes In UML, such a relationship is indicated by an association
Associations may be annotated with information that describes the association
EmployeeDepartment
Manager
is-member-of
is-managed-by
manages
![Page 17: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/17.jpg)
OO Design - Sudarsun S 17
Object identification Identifying objects (or object classes) is the
most difficult part of object oriented design There is no “magic formula” for object
identification It relies on the skill, experience
and domain knowledge of system designers Object identification is an iterative process
You are unlikely to get it right first time
![Page 18: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/18.jpg)
OO Design - Sudarsun S 18
Approaches to identification Use a grammatical approach based on a natural
language description of the system (used in HOOD method)
Base the identification on tangible things in the application domain
Use a behavioural approach and identify objects based on what participates in what behaviour
Use a scenario-based analysis – the objects, attributes and methods in each scenario are identified
![Page 19: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/19.jpg)
OO Design - Sudarsun S 19
Object interface specification Object interfaces have to be specified so that
the objects and other components can be designed in parallel
Designers should avoid designing the interface representation but should hide this in the object itself
Objects may have several interfaces which are viewpoints on the methods provided
![Page 20: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/20.jpg)
OO Design - Sudarsun S 20
Examples of design models Sub-system models that show logical groupings of
objects into coherent subsystems UML package diagrams
Sequence models that show the sequence of object interactions UML sequence diagrams
State machine models that show how individual objects change their state in response to events UML statechart diagrams
Other models include use-case models, aggregation models, generalisation models,etc.
![Page 21: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/21.jpg)
OO Design - Sudarsun S 21
Weather station subsystems«subsystem»
Interface
CommsController
WeatherStation
«subsystem»Data collection
«subsystem»Instruments
Air thermometer
WeatherData
Ground thermometer
Anemometer
WindVane
RainGauge
InstrumentStatus
Barometer
![Page 22: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/22.jpg)
OO Design - Sudarsun S 22
Weather station - data collection sequence
:CommsController
request (report)
acknowledge ()report ()
summarise ()
reply (report)
acknowledge ()
send (report)
:WeatherStation :WeatherData
![Page 23: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/23.jpg)
OO Design - Sudarsun S 23
State charts Object states State transitions triggered by requests to
objects
Shutdown Waiting Testing
Transmitting
Collecting
Summarising
Calibrating
transmission done
calibrate ()
test ()startup ()
shutdown ()
calibration OK
test complete
weather summarycomplete
clock collectiondone
Operation
reportWeather ()
![Page 24: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/24.jpg)
OO Design - Sudarsun S 24
OO Design Process – Access Layer
Create Mirror classes: For every business class identified and created, create one access class.
Simplify classes and their relationships – to eliminate redundant classes and structures
Redundant classes: Do not keep 2 classes that perform similar request and results translation activities. Select one and eliminate the other.
Methods: Revisit the classes that consist of only one or two methods to see if they can be eliminated or combined with existing classes.
![Page 25: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/25.jpg)
OO Design - Sudarsun S 25
Object Oriented Design Process Design the view layer classes
Design the macro & micro level user interface, identifying view layer objects
Test usability and user satisfaction From the UML class diagram, begin to extrapolate the
classes to build and classes to reuse. Also think about the inheritance structure. If we have several classes that seem related but have
specific differences, probably it means an inheritance structure.
All designed components must trace back to the user requirements.
![Page 26: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/26.jpg)
OO Design - Sudarsun S 26
Example: Invoice
![Page 27: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/27.jpg)
OO Design - Sudarsun S 27
Example: Invoice
Classes that come to mind: Invoice, LineItem, and Customer
Good idea to keep a list of candidate classes
Brainstorm, simply put all ideas for classes onto the list
You can cross not useful ones later
![Page 28: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/28.jpg)
OO Design - Sudarsun S 28
Finding Classes Keep the following points in mind:
Class represents set of objects with the same behavior Entities with multiple occurrences in problem
description are good candidates for objects Find out what they have in common Design classes to capture commonalities
Represent some entities as objects, others as primitive types Should we make a class Address or use a String?
Not all classes can be discovered in analysis phase Some classes may already exist
![Page 29: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/29.jpg)
OO Design - Sudarsun S 29
CRC Card CRC Card Describes a class, its responsibilities, and its
collaborators Use an index card for each class Pick the class that should be responsible for each
method (verb) Write the responsibility onto the class card Indicate what other classes are needed to fulfill
responsibility (collaborators)
![Page 30: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/30.jpg)
OO Design - Sudarsun S 30
CRC Card
![Page 31: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/31.jpg)
OO Design - Sudarsun S 31
Self Check
1. Suppose the invoice is to be saved to a file. Name a likely collaborator.
2. Looking at the invoice, what is a likely responsibility of the Customer class?
3. What do you do if a CRC card has ten responsibilities?
![Page 32: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/32.jpg)
OO Design - Sudarsun S 32
Answers
1. FileWriter
2. To produce the shipping address of the customer.
3. Reword the responsibilities so that they are at a higher level, or come up with more classes to handle the responsibilities.
![Page 33: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/33.jpg)
OO Design - Sudarsun S 33
Relationships Between Classes
Inheritance Aggregation Dependency
![Page 34: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/34.jpg)
OO Design - Sudarsun S 34
Inheritance
Is-a relationship Relationship between a more general
class (superclass) anda more specialized class (subclass)
Every savings account is a bank account
Continued…
![Page 35: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/35.jpg)
OO Design - Sudarsun S 35
Inheritance
Every circle is an ellipse (with equal width and height)
It is sometimes abused Should the class Tire be a subclass of a
class Circle? The has-a relationship would be more appropriate
![Page 36: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/36.jpg)
OO Design - Sudarsun S 36
Aggregation Has-a relationship Objects of one class contain references to objects of
another class Use an instance variable
A tire has a circle as its boundary:
Every car has a tire (in fact, it has four)
class Tire{ . . . private String rating; private Circle boundary;}
![Page 37: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/37.jpg)
OO Design - Sudarsun S 37
Example
class Car extends Vehicle{ . . . private Tire[] tires;}
![Page 38: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/38.jpg)
OO Design - Sudarsun S 38
Example
UML Notation for Inheritance and Aggregation
![Page 39: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/39.jpg)
OO Design - Sudarsun S 39
Dependency
Uses relationship Example: many of our applications depend
on the Scanner class to read input Aggregation is a stronger form of
dependency Use aggregation to remember another
object between method calls
![Page 40: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/40.jpg)
OO Design - Sudarsun S 40
UML Relationship SymbolsRelationship Symbol Line Style Arrow TipInheritance Solid Triangle
Interface Implementation
Dotted Triangle
Aggregation Solid Diamond
Dependency Dotted Open
![Page 41: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/41.jpg)
OO Design - Sudarsun S 41
Self Check
4. Consider the Bank and BankAccount classes. How are they related?
5. Consider the BankAccount and SavingsAccount objects. How are they related?
6. Consider the BankAccountTester class. Which classes does it depend on?
![Page 42: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/42.jpg)
OO Design - Sudarsun S 42
Answers
4. Through aggregation. The bank manages bank account objects.
5. Through inheritance.
6. The BankAccount, System, and PrintStream classes.
![Page 43: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/43.jpg)
OO Design - Sudarsun S 43
Attributes and Methods in UML
Attributes and Methods in a Class Diagram
![Page 44: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/44.jpg)
OO Design - Sudarsun S 44
Multiplicities any number (zero or more): * one or more: 1..* zero or one: 0..1 exactly one: 1
An Aggregation Relationship with Multiplicities
![Page 45: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/45.jpg)
OO Design - Sudarsun S 45
Aggregation and Association
Association: more general relationship between classes
Use early in the design phase A class is associated with another if you can
navigate from objects of one class to objects of the other
Given a Bank object, you can navigate to Customer objects
Continued…
![Page 46: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/46.jpg)
OO Design - Sudarsun S 46
Aggregation and Association
An Association Relationship
![Page 47: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/47.jpg)
OO Design - Sudarsun S 47
Five-Part Development Process
Gather requirements Use CRC cards to find classes, responsibilities,
and collaborators Use UML diagrams to record class relationships Use javadoc to document method behavior Implement your program
![Page 48: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/48.jpg)
OO Design - Sudarsun S 48
Printing an Invoice – Requirements Task: print out an invoice Invoice: describes the charges for a set of products in certain
quantities Omit complexities
Dates, taxes, and invoice and customer numbers Print invoice
Billing address, all line items, amount due Line item
Description, unit price, quantity ordered, total price For simplicity, do not provide a user interface Test program: adds line items to the invoice and then prints it
Continued…
![Page 49: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/49.jpg)
OO Design - Sudarsun S 49
Sample Invoice
![Page 50: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/50.jpg)
OO Design - Sudarsun S 50
CRC Cards
Discover classes Nouns are possible classes
InvoiceAddressLineItemProductDescriptionPriceQuantityTotalAmount Due
![Page 51: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/51.jpg)
OO Design - Sudarsun S 51
CRC Cards
Analyze classes
InvoiceAddressLineItem // Records the product and the quantityProductDescription // Field of the Product classPrice // Field of the Product classQuantity // Not an attribute of a ProductTotal // Computed–not stored anywhereAmount Due // Computed–not stored anywhere
Continued…
![Page 52: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/52.jpg)
OO Design - Sudarsun S 52
CRC Cards
Classes after a process of elimination
InvoiceAddressLineItemProduct
![Page 53: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/53.jpg)
OO Design - Sudarsun S 53
CRC Cards for Printing Invoice Invoice and Address must be able to
format themselves:
![Page 54: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/54.jpg)
OO Design - Sudarsun S 54
CRC Cards for Printing Invoice Add collaborators to invoice card:
![Page 55: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/55.jpg)
OO Design - Sudarsun S 55
CRC Cards for Printing Invoice
Product and LineItem CRC cards:
![Page 56: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/56.jpg)
OO Design - Sudarsun S 56
CRC Cards for Printing Invoice Invoice must be populated with products
and quantities:
![Page 57: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/57.jpg)
OO Design - Sudarsun S 57
Printing an Invoice – UML Diagrams
The Relationships Between the Invoice Classes
![Page 58: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/58.jpg)
OO Design - Sudarsun S 58
Method Documentation
Use javadoc documentation to record the behavior of the classes
Leave the body of the methods blank Run javadoc to obtain formatted version of
documentation in HTML format Advantages:
Share HTML documentation with other team members Format is immediately useful: Java source files Supply the comments of the key methods
![Page 59: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/59.jpg)
OO Design - Sudarsun S 59
Method Documentation – Invoice class
/** Describes an invoice for a set of purchased products.*/public class Invoice{ /** Adds a charge for a product to this invoice. @param aProduct the product that the customer ordered @param quantity the quantity of the product */ public void add(Product aProduct, int quantity) { }
/** Formats the invoice. @return the formatted invoice */ public String format() { }}
![Page 60: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/60.jpg)
OO Design - Sudarsun S 60
Method Documentation – LineItem class
/** Describes a quantity of an article to purchase and its price.*/public class LineItem{ /** Computes the total cost of this line item. @return the total price */ public double getTotalPrice() { }
/** Formats this item. @return a formatted string of this line item */ public String format() { }}
![Page 61: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/61.jpg)
OO Design - Sudarsun S 61
Method Documentation – Product class
/** Describes a product with a description and a price.*/public class Product{ /** Gets the product description. @return the description */ public String getDescription() { }
/** Gets the product price. @return the unit price */ public double getPrice() { }}
![Page 62: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/62.jpg)
OO Design - Sudarsun S 62
Method Documentation – Address class
/** Describes a mailing address.*/public class Address{ /** Formats the address. @return the address as a string with three lines */ public String format() { }}
![Page 63: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/63.jpg)
OO Design - Sudarsun S 63
Implementation
Invoice aggregates Address and LineItem
Every invoice has one billing address An invoice can have many line items:
public class Invoice{ . . . private Address billingAddress; private ArrayList<LineItem> items;}
![Page 64: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/64.jpg)
OO Design - Sudarsun S 64
Implementation
A line item needs to store a Product object and quantity:
public class LineItem{ . . . private int quantity; private Product theProduct;}
![Page 65: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/65.jpg)
OO Design - Sudarsun S 65
Implementation The methods themselves are now very easy Example:
getTotalPrice of LineItem gets the unit price of the product and multiplies it with the quantity
/** Computes the total cost of this line item. @return the total price*/public double getTotalPrice(){ return theProduct.getPrice() * quantity;}
![Page 66: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/66.jpg)
OO Design - Sudarsun S 66
Self Check
7. Which class is responsible for computing the amount due? What are its collaborators for this task?
8. Why do the format methods return String objects instead of directly printing to System.out?
![Page 67: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/67.jpg)
OO Design - Sudarsun S 67
Answers
7. The Invoice class is responsible for computing the amount due. It collaborates with the LineItem class.
8. This design decision reduces coupling. It enables us to reuse the classes when we want to show the invoice in a dialog box or on a web page.
![Page 68: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/68.jpg)
OO Design - Sudarsun S 68
Suh’s Axioms of OOD The independence axiom: Maintain
independence of components. Each component must satisfy its requirements without affecting other requirements.
The information axiom: Minimize the information content of the design. It is concerned with simplicity. Rely on Occam’s Razor
![Page 69: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/69.jpg)
OO Design - Sudarsun S 69
Occum’s Razor rule of simplicity
The best designs usually involve the least complex code but not necessarily the fewest number of classes or methods.
Minimizing complexity should be the goal, because that produces the most easily maintained and enhanced application.
In an object-oriented system, the best way to minimize complexity is to use inheritance and the system’s built-in classes and to add as little as possible to what already is there.
![Page 70: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/70.jpg)
OO Design - Sudarsun S 70
Some Corollaries… Uncoupled design Single purpose Large number of simple classes Strong mapping Standardization Design with inheritance
![Page 71: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/71.jpg)
OO Design - Sudarsun S 71
Uncoupled Design Coupling is a measure of the strength of
association established by a connection from one object or software component to another.
Types Interaction coupling
amount and complexity of messages between components. Preferred to be minimal What happens when high and low ?
Inheritance coupling coupling between super and sub classes coupling in terms of attributes and methods Preferred to be high What happens when high and low ? { override all, unused
methods }
![Page 72: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/72.jpg)
OO Design - Sudarsun S 72
Cohesion Cohesion reflects the “single-purposeness” of an
object. Highly cohesion Lower coupling Method cohesion: method carrying one function. A method that carries multiple functions is
undesirable. Class cohesion: All the class’s methods and
attributes are highly cohesive, meaning to be used by internal methods or derived classes’ methods.
![Page 73: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/73.jpg)
OO Design - Sudarsun S 73
Corollary 2: Single Purpose Every class should be clearly defined and
necessary in the context of achieving the system’s goals.
When we document a class, we should be able to explain its purpose in a sentence or two.
If we cannot, then the class should be subdivided into independent pieces.
Each method must provide only one service. Each method should be of moderate size, no
more than a page; half a page is better.
![Page 74: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/74.jpg)
OO Design - Sudarsun S 74
Achieving Multiple Inheritance What is Single inheritance? What is the problem with Multiple Inheritance ? What is the ideal case for MI ? In C++ objects can inherit behavior from
unrelated areas of the class tree. How to determine which behavior to get from
which class, particularly when several ancestors define the same method.
Virtual Inheritance !!??
![Page 75: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/75.jpg)
OO Design - Sudarsun S 75
Class Visibility Purpose of Access Specifiers ? Difference between c++ struct and class ? The class’s protocol or the messages that a class
understands, can be hidden from other objects (private protocol) or made available to other objects (public protocol).
Public protocols define the functionality and external messages of an object.
Private protocols define the implementation of an object. The lack of well-designed protocol can manifest itself as
encapsulation leakage. It happens when details about a class’s internal implementation are disclosed through the interface
![Page 76: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/76.jpg)
OO Design - Sudarsun S 76
Design patterns A design pattern is a way of reusing abstract knowledge
about a problem and its solution Patterns are devices that allow programs to share knowledge
about their design A pattern is a description of the problem and the essence of
its solution Documenting patterns is one way to reuse and share the
information about how it is best to solve a specific design problem A pattern should be sufficiently abstract to be reused in
different settings Patterns often rely on object characteristics such as
inheritance and polymorphism
![Page 77: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/77.jpg)
OO Design - Sudarsun S 77
Pattern elements
Name A meaningful pattern identifier
Problem description Solution description
Not a concrete design but a template for a design solution that can be instantiated in different ways
Consequences The results and trade-offs of applying the pattern
![Page 78: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/78.jpg)
OO Design - Sudarsun S 78
Types of Patterns
Creational Abstract Factory
Structural Adapter Façade Proxy
Behavioral Observer Mediator
![Page 79: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/79.jpg)
OO Design - Sudarsun S 79
Patterns by Example:Multiple displays enabled by Observer
A=10%B=40%C=30%D=20%
Application data
A
BC
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modifications
![Page 80: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/80.jpg)
OO Design - Sudarsun S 80
The Observer pattern Name
Observer
Description Separates the display of object state from the object itself
Problem description Used when multiple displays of state are needed
Solution description See slide with UML description
Consequences Optimisations to enhance display performance are impractical
![Page 81: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/81.jpg)
OO Design - Sudarsun S 81
The Observer pattern
Subject
attach (Observer)
detach (Observer)
Notify ()
Observer
Update()
Concrete Observer
Update()
observerState
Concrete Subject
GetState()
SetState()
subjectState
observers
subject
For all x in observers{ x Update(); }
observerState= subject getState();
![Page 82: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/82.jpg)
OO Design - Sudarsun S 82
The Mediator Pattern Description
Define an object that encapsulates how a set of objects interact Mediator promotes loose coupling by keeping objects from referring to
each other explicitly It lets you vary their interaction independently
Applicability Complex interaction exists You do not want to bury the interaction in the objects Distributed behavior should be customizable without a lot of sub
classing Consequences
Limits sub classing Decouples colleagues Simplifies object protocols Abstracts how objects cooperate Centralizes control
![Page 83: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/83.jpg)
OO Design - Sudarsun S 83
The Mediator Pattern
![Page 84: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/84.jpg)
OO Design - Sudarsun S 84
The Façade Pattern Description
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Applicability Need to provide a simple interface to a complex system Need to decouple a subsystem from its clients Need to provide an interface to a software layer
Consequences Shields clients from subsystem components Promotes weak coupling between the subsystem and its clients
![Page 85: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/85.jpg)
OO Design - Sudarsun S 85
Facade Pattern: Problem
Client Classes
Subsystem classes
Need to communicatewith
![Page 86: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/86.jpg)
OO Design - Sudarsun S 86
Facade Pattern: Solution
Client Classes
Subsystem classes
Facade
![Page 87: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/87.jpg)
OO Design - Sudarsun S 87
The Façade Pattern
![Page 88: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/88.jpg)
OO Design - Sudarsun S 88
The Proxy Pattern
Description Provide a surrogate or placeholder for another object to
control access to it.
Applicability Remote proxies can hide the fact that a real object is in
another address space Virtual proxies can create expensive objects on demand. Protection proxies can control access to an object. Smart references can perform additional action above a
simple pointer
![Page 89: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/89.jpg)
OO Design - Sudarsun S 89
The Proxy Pattern
![Page 90: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/90.jpg)
OO Design - Sudarsun S 90
The Adapter Pattern Description
Convert the interface of a class into another interface clients expect
Adapter lets classes work together that could not otherwise because of incompatible interfaces
Applicability Need to use an existing class whose interface does not
match Need to make use of incompatible classes
Consequences Class adapter commits to the concrete Adapter class Class adapter introduces only one object and no pointer
indirection
![Page 91: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/91.jpg)
OO Design - Sudarsun S 91
The Adapter Pattern
![Page 92: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/92.jpg)
OO Design - Sudarsun S 92
The Abstract Factory Pattern Description
Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Applicability Need to abstract from details of implementation of products Need to have multiple families of products Need to enforce families of products that must be used together Need to hide product implementations and just present interfaces
Consequences Isolates concrete classes Makes exchanging product families easy Promotes consistency among products Supporting new kinds (in each family) of products is difficult
![Page 93: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/93.jpg)
OO Design - Sudarsun S 93
The Abstract Factory PatternAbstractFactory
CreateProductA()
CreateProductB()
ConcreteFactory1
Client
ProductA1ProductA2
AbstractProductA
ProductB2 ProductB1
AbstractProductB
ConcreteFactory2
CreateProductA()
CreateProductB()
![Page 94: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/94.jpg)
OO Design - Sudarsun S 94
Abstract Factory ExampleWidgetFactory
CreateScrollbar()
CreateWindow()
Window
ScrollBarWWidgetFactory
MacWidgetFactory
Client
WWindowMacWindow
MacScrollBar WScrollBar
One for each standard.
![Page 95: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/95.jpg)
OO Design - Sudarsun S 95
What is dependency management? What bearing does DM have on software? What is the result of poor DM? What is the advantage of good DM?
Dependency Management
![Page 96: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/96.jpg)
OO Design - Sudarsun S 96
What is dependency management?
A simple idea - as interdependencies increase, features like reusability, flexibility, and maintainability decrease.
Dependency management is controlling interdependencies.
![Page 97: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/97.jpg)
OO Design - Sudarsun S 97
What bearing does DM have on software?
Coupling and cohesion are the eternal concerns of software development
One can say that OO is just a set of tools and techniques for Dependency Management
![Page 98: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/98.jpg)
OO Design - Sudarsun S 98
What is the penalty for practicing poor DM?
It is rigid It is fragile It is not reusable It has high viscosity
A system with poor dependency structure will typically exhibit these four negative traits:
![Page 99: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/99.jpg)
OO Design - Sudarsun S 99
It is Rigid
The impact of a change cannot be predicted If not predicted, it cannot be estimated Time and cost cannot be quantified Managers become reluctant to authorize change Official Rigidity for “Roach Motel” modules
Rigidity is the inability to be changed
![Page 100: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/100.jpg)
OO Design - Sudarsun S 100
Changes with Rigidity
The System
Officially Rigid Area
Where the change should be made
Where the change must be made now
Are we containing risk, or spreading rot?
![Page 101: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/101.jpg)
OO Design - Sudarsun S 101
It is Fragile
A single change requires a cascade of subsequent changes
New errors appear in areas that seem unconnected to the changed areas
Quality is unpredictable. The development team loses
credibility
Software changes seem to exhibit non-local effects
![Page 102: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/102.jpg)
OO Design - Sudarsun S 102
Increasing RiskDefects v. Cumulative Modifications
Systems tend to become increasingly fragile over time. Intentional, plannedpartial rewrites may be necessary to sustain growth and maintenance.
Changes
Pro
babi
lity
of
intr
oduc
ing
a bu
g
1.0
![Page 103: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/103.jpg)
OO Design - Sudarsun S 103
It is not reusable
Desirable parts of the design are dependent upon undesirable parts
The work and risk of extracting the desirable part may exceed the cost of redeveloping from scratch.
![Page 104: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/104.jpg)
OO Design - Sudarsun S 104
The TrailerThe Trailer
![Page 105: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/105.jpg)
OO Design - Sudarsun S 105
It has high viscosity
When the “right changes” are much more difficult than hacking, the viscosity of the system is high.
Over time, it will become increasingly difficult to continue developing the product.
Viscosity is resistance to fluid motion.
![Page 106: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/106.jpg)
OO Design - Sudarsun S 106
What is the benefit of good DM?Interdependencies are managed, with firewalls
separating aspects that need to vary independently.
More FlexibleLess fragile,
the bugs are boxed in
Easier to reuse Easier to make the right change
![Page 107: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/107.jpg)
OO Design - Sudarsun S 107
What causes “Code Rot”?
A case study “The Copy Routine”
It’s been blamed on stupidity, lack of discipline, and phases of the moon, but...
![Page 108: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/108.jpg)
OO Design - Sudarsun S 108
First VersionAll designs start well
The program is an overnight success!How could it be more simple, elegant, and maintainable?
ReadKeyboard
Copy
W ritePRinter
void copy(void){
int ch;while( (ch=ReadKeyboard()) != EOF)
WritePrinter(ch);}
![Page 109: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/109.jpg)
OO Design - Sudarsun S 109
Second Version
We sometimes want to read from paper tape reader.
We could put a parameter in the call, but we have hundreds of users already!
No big deal, this is just an exception… we can make it work.
Oh, no! Nobody said the requirements might change!
![Page 110: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/110.jpg)
OO Design - Sudarsun S 110
Second Version Design
ReadKeyboard
Copy
WritePrinter
ReadTape
bool GtapeReader = false; // remember to clear
void copy(void){
int ch;while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF)
WritePrinter(ch);}
![Page 111: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/111.jpg)
OO Design - Sudarsun S 111
Third VersionHow unexpected! Requirements changed again!
bool GtapeReader = false; Bool GtapePunch = false; // remember to clear
void copy(void){
int ch;while( (ch=GtapeReader ? ReadTape() : ReadKeyboard()) != EOF)
GtapePunch ? WritePunch(ch) : WritePrinter(ch);}
It seems that sometimes we need to write to a paper tape punch. We’ve had this problem before, and just added a flag. Looks like it should work again.
![Page 112: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/112.jpg)
OO Design - Sudarsun S 112
Example of a Good DesignFirst and only version.
void Copy(){
int c;while( (c=getchar()) != EOF)
putchar(c);}
But wait! Aren’t we supposed to be learning OO design? This isn’t OO is it?
![Page 113: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/113.jpg)
OO Design - Sudarsun S 113
…is it?
FILE is an abstraction It represents some kind of byte stream It has many variations
It has methodsRead, Write, getchar, putchar, etcThe methods are *dynamically* bound
It is a small program based on abstractions!
FILE is a class, just implemented differently.
![Page 114: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/114.jpg)
OO Design - Sudarsun S 114
Rephrased in OO
Copy
Reader Writer
KeyboardReader PrinterWriter
«interface» «interface»
interface Reader{ char read(); }
interface Writer{ void write(char c); }
public class Copy{
Copy(Reader r, Writer w){
itsReader = r;itsWriter = w;
}public void copy(){
int c;while( (c==itsReader.read()) != EOF )
itsWriter.write(c);}private Reader itsReader;private Writer itsWriter;
}
![Page 115: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/115.jpg)
OO Design - Sudarsun S 115
Class Design Principles
SRP: The Single Responsibility Principle OCP: The Open/Closed Principle LSP: The Liskov Substitution Principle ISP: The Interface Segregation Principle DIP: The Dependency Inversion Principle
From: Agile Software Development: Principles, Patterns, and Practices.Robert C. Martin, Prentice Hall, 2002.
![Page 116: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/116.jpg)
OO Design - Sudarsun S 116
The Single Responsibility Principle
A class should have one, and only one, reason to change.
+ CalcPay+ ReportHours+ W riteEmployee
EmployeePayroll
![Page 117: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/117.jpg)
OO Design - Sudarsun S 117
Open/Closed Principle
A principle which states that we should add new functionality by adding new code, not by editing old code.
Defines a lot of the value of OO programming Abstraction is the key
“Modules should be open for extension, but closed for modification”-Bertrand Meyer
![Page 118: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/118.jpg)
OO Design - Sudarsun S 118
Abstraction is Key
Client/Server relationships are “open”
Changes to servers cause changes to clients
Abstract servers “close” clients to changes in implementation.
Abstraction is the most important word in OOD
Client Server
ClientAbstractServer
ConcreteServer
![Page 119: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/119.jpg)
OO Design - Sudarsun S 119
The Shape Example Procedural (not closed) implementation OO (closed) implementation
![Page 120: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/120.jpg)
OO Design - Sudarsun S 120
Procedural (open) versionenum ShapeType {circle, square};struct Shape {enum ShapeType itsType;};
struct Circle {
enum ShapeType itsType;double itsRadius;Point itsCenter;
};void DrawCircle(struct Circle*)
struct Square {
enum ShapeType itsType;double itsSide;Point itsTopLeft;
};void DrawSquare(struct Square*)
#include <Shape.h>#include <Circle.h>#include <Square.h>
typedef struct Shape* ShapePtr;
void DrawAllShapes(ShapePtr list[], int n){
int i;for( i=0; i< n, i++ ){
ShapePtr s = list[i];switch ( s->itsType ){case square:
DrawSquare((struct Square*)s);break;
case circle:DrawCircle((struct Circle*)s);break;
}}
}
Shape.h
Circle.h
Square.h
DrawAllShapes.c
![Page 121: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/121.jpg)
OO Design - Sudarsun S 121
What is wrong with the code?
DrawAllShapes is not closed.Switch/case tend to recur in diverse places. If we add a shape, we add to the switch/caseAll switch/case statements must be found and editd.Switch/Case statements are seldom this tidyWhen we add to the enum, we must rebuild
everything The software is both rigid and brittle
It can be demonstrated to work. Isn’t that the important thing?
![Page 122: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/122.jpg)
OO Design - Sudarsun S 122
A Closed Implementation
Class Shape{public:
virtual void Draw() const =0;};
#include <Shape.h>
void DrawAllShapes(Shape* list[],int n){
for(int i=0; i< n; i++)list[i]->draw();
}
Shape.h
DrawAllShapes.cpp
Circle.h
Square.h
Class Square: public Shape{public:
virtual void Draw() const;};
Class Circle: public Shape{public:
virtual void Draw() const;};
![Page 123: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/123.jpg)
OO Design - Sudarsun S 123
Strategic Closure
Closure Against What? Closure is strategic. You have to choose which changes you’ll isolate yourself
against. What if we have to draw all circles first? Now DrawAllShapes must be edited (or we
have to hack something) Opened Where?
Somewhere, someone has to instantiate the individual shapes. It’s best if we can keep the dependencies confined
Use abstraction to gain explicit closure provide class methods which can be dynamically invoked
to determine general policy decisions e.g. draw Squares before Circles
design using abstract ancestor classes Use "Data-Driven" approach to achieve closure
place volatile policy decisions in a separate location e.g. a file or a separate object
minimizes future change locations
No program is 100% closed.
![Page 124: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/124.jpg)
OO Design - Sudarsun S 124
Liskov Substitution Principle
All derived classes must be substitutable for their base classes
This principle guides us in the creation of abstractions.
Derived classes must be usable through the base class interface, without the need for the user to know the difference.
![Page 125: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/125.jpg)
OO Design - Sudarsun S 125
Square/Rectangle
Square
Rectangle
+S etH eight()+S etW idth()
-he ight : rea l-w id th : rea l
A square is-a rectangle, right? So lets consider Square as a subtype of Rectangle.
void Square::SetWidth(double w){
width = w;height = w;
}void Square::SetHeight(double h){
width = h; height = h;}
We can make it work:
Uh, oh. Thisdoesn’t quite seem to fit
![Page 126: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/126.jpg)
OO Design - Sudarsun S 126
Substitution… denied!
It is reasonable for users of a rectangle to expect that height and width may change independently.
These expectations are preconditions and postconditions Bertrand Meyer calls it “Design by Contract” Post condition contract for rectangle is
width = new Width height = old height
Square violates Rectangle’s contract
![Page 127: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/127.jpg)
OO Design - Sudarsun S 127
Liskov Substitution Principle A client of rectangle expects height and
width to be changed independentlyvoid setAspectRatio( Rectange* r, double ratio );
By deriving Square from Rectangle, we are allowing someone to set the aspect ratio of a Square !
We can still make it work if ( typeid(r) == typeid(Rectangle) )Violates Open/Closed Principle !
![Page 128: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/128.jpg)
OO Design - Sudarsun S 128
Liskov Substitution Principle Design by Contract
Bertrand Meyer Pre-conditions, Post-conditions, invariants
Rectangle's postconditions for setWidth() width = newWidth length = oldLength
Square can require no more of clients, nor promise any less Doesn't maintain invariant of length Violates the contract
![Page 129: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/129.jpg)
OO Design - Sudarsun S 129
Design by Contract Advertised Behavior of an object:
advertised Requirements (Preconditions) advertised Promises (Postconditions)
When redefining a method in a derivate class, you may only replace its precondition by a weaker one, and
its postcondition by a stronger oneB. Meyer, 1988
Derived class services should require no more and promise no less
int Base::f(int x);// REQUIRE: x is odd// PROMISE: return even int
int Derived::f(int x);// REQUIRE: x is int// PROMISE: return 8
![Page 130: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/130.jpg)
OO Design - Sudarsun S 130
LSP is about Semantics and Replacement
The meaning and purpose of every method and class must be clearly documented Lack of user understanding will induce de facto violations of LSP
Replaceability is crucial Whenever any class is referenced by any code in any system, any future or existing subclasses of that class must be
100% replaceable Because, sooner or later, someone will substitute a subclass;
it’s almost inevitable.
![Page 131: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/131.jpg)
OO Design - Sudarsun S 131
Dependency Inversion Principle
Details should depend on abstractions. Abstractions should not depend on details.
Copy
Reader W riter
KeyboardReader PrinterW riter
ReadKeyboard
Copy
W ritePRinter
V.
![Page 132: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/132.jpg)
OO Design - Sudarsun S 132
Dependency Inversion PrincipleI. High-level modules should not depend on low-level modules.
Both should depend on abstractions.
II. Abstractions should not depend on details.
Details should depend on abstractionsR. Martin, 1996
OCP states the goal; DIP states the mechanism A base class in an inheritance hierarchy should not know
any of its subclasses Modules with detailed implementations are not depended
upon, but depend themselves upon abstractions
![Page 133: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/133.jpg)
OO Design - Sudarsun S 133
Procedural vs. OO Architecture
Procedural Architecture
Object-Oriented Architecture
![Page 134: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/134.jpg)
OO Design - Sudarsun S 134
DIP Applied on ExampleCopy
Reader Writer
KeyboardReader
PrinterWriter
DiskWriter
class Reader { public: virtual int read()=0;};
class Writer { public: virtual void write(int)=0;};
void Copy(Reader& r, Writer& w){ int c; while((c = r.read()) != EOF) w.write(c);}
![Page 135: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/135.jpg)
OO Design - Sudarsun S 135
Interface Segregation Principle
Sometimes class methods have various groupings.
These classes are used for different purposes. Not all users rely upon all methods. This lack of cohesion can cause serious
dependency problems These problems can be refactored away.
Helps deal with “fat” or inappropriate interfaces
![Page 136: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/136.jpg)
OO Design - Sudarsun S 136
Interface Pollution by “collection”
Client 3Client 2Client 1
Server
+ C1Function()+ C2Function()+ C3Function()
Distinct clients of our class have distinct interface needs.
![Page 137: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/137.jpg)
OO Design - Sudarsun S 137
A Segregated ExampleClient 3Client 2Client 1
Client 3InterfaceClient 2InterfaceClient 1Interface«interface» «interface»«interface»
Server
+ C1Function()+ C2Function()+ C3Function
+ C1Function() + C2Function() + C3Function()
![Page 138: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/138.jpg)
OO Design - Sudarsun S 138
ATM UI Example
TransferDepositW ithdraw
«interface»ATM UI
+ G etW ithdraw AmountAndAccount()+ G etDepositAmountAndAccount()+ G etTransferAmountAndAccounts()
French ATM UI English ATM UI
![Page 139: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/139.jpg)
OO Design - Sudarsun S 139
A Segregated ATM UI ExampleTransferW ithdrawDeposit
ATM Transfer UIATM W ithdraw UIATM Deposit UI«interface» «interface»«interface»
+ GetDepositAm ountAndAccount() + GetW ithdrawAm ountAndAccount + GetTransferAm ountAndAccounts()
«interface»ATM UI
+ GetW ithdrawAmountAndAccount()+ GetDepositAmountAndAccount()+ GetTransferAmountAndAccounts()
French ATM UI English ATM UI
![Page 140: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/140.jpg)
OO Design - Sudarsun S 140
Logger ExampleLog ControlApplicationCode needing to
log som ething
LogManager
EventLog
«interface»
«interface»
M anagedEventLog
+ Log(s: string*)+ SendLotToFile(nam e)+ LogToMem (size)+ LogToConsole()
+ Log(s: string*)
+ SendLotToFile(name)+ LogToM em(size)+ LogToConsole()
![Page 141: Object Oriented Design](https://reader033.fdocuments.us/reader033/viewer/2022061210/548f42f7b4795904298b47b7/html5/thumbnails/141.jpg)
OO Design - Sudarsun S 141
Four Class Design Principles - Review
OCP: Extend function without editing codeLSP: Child instances substitute cleanly for baseDIP: Depend on abstractions instead of detailsISP: Split interfaces to manage dependencies