Class design guidelines. Most of this material comes from Horstmann, Cay: Object-Oriented Design & Patterns (chapter 3)

Transcription

1 Class design guidelines Most of this material comes from Horstmann, Cay: Object-Oriented Design & Patterns (chapter 3) 1

2 Encapsulation Classes can be implemented many different ways each has advantages & disadvantages improvement/revision always a possibility Encapsulation facilitates change in implementation without affecting client code 2

3 Information Hiding Public interface of object & private representation of object usually kept distinct allows certain aspects of object to be hidden from view distinguishes ability to perform a task from specific steps needed to do so public interface of object consists of operations other objects can request the object to perform 3

4 Why private data fields? Public instance fields box us in anything public can be, and probably will be, used by client programmers any changes made to class must accommodate this dependency For example, if the Day class had public members representing month, day and year, a switch to julian representation would involve either invalidating this code or significant (and cumbersome) redundancy 4

5 The Importance of Encapsulation Even a simple class can benefit from different implementations Users are unaware of implementation Public instance variables would have blocked improvement in Day class 5

6 Day class example - public data fields year, day, month Suppose we switch to julian representation Can't just wave magic wand to replace all d.year with d.getyear()in client code How about d.year++? d = new Day(d.getDay(), d.getmonth(), d.getyear() + 1) Gets really inefficient in Julian representation Don't use public fields, even for "simple" classes 6

7 Advantages of encapsulation Restricts range of program affected by any change to the methods of the class Allows for software evolution over time without useless baggage carried into next program version 7

8 Accessors & mutators Accessor methods report but do not change object state Mutator methods modify object state Classes without mutators are immutable String class is an example; can assign a new object reference to a String variable, but can t make changes to the object 8

9 Don't Supply a Mutator for every Accessor Day has getyear, getdate and getmonth accessors, but does not have setyear, setmonth,setdate mutators These mutators would not work well; for example: Day deadline = new Day(2001, 1, 31); deadline.setmonth(2); // ERROR deadline.setdate(28); 9

10 Example continues Maybe we should call setdate first? Day d = new Day(2001, 2, 28); d.setdate(31); // ERROR d.setmonth(3); GregorianCalendar implements confusing rollover - silently gets the wrong result instead of error: suppose date initially set to January 31, then month set to February instead of error message, get date set to March 3 10

11 Sharing Mutable References References to immutable objects can be freely shared Don't share mutable references: example class Employee {... public String getname() { return name; } public double getsalary() { return salary; } public Date gethiredate() { return hiredate; } // note: Date objects are mutable... } 11

12 Example continued Pitfall: Employee harry =...; Date d = harry.gethiredate(); d.settime(t); // changes Harry's state Remedy: Use clone() public Date gethiredate() { return (Date)hireDate.clone(); } 12

13 Final Instance Fields Good idea to mark immutable instance fields as final: private final int day; final object reference can still refer to mutating object: private final ArrayList elements; elements can't refer to another array list The contents of the array list can change 13

14 Separating Accessors and Mutators If we call a method to access an object, we don't expect the object to mutate Rule of thumb: Mutators should return void Example of violation (from Java API): StringTokenizer t =...; String s = t.nexttoken(); Yields current token and advances iteration - what if I want to read the current token again? 14

15 Separating Accessors and Mutators Better interface: String gettoken(); void nexttoken(); Even more convenient: String gettoken(); String nexttoken(); // returns current Refine rule of thumb: Mutators can return a convenience value, provided there is also an accessor to get the same value 15

16 Side Effects Accessor: no change to object Mutator: changes object state Side effect: change to another object Parameter variable static object Avoid side effects--they confuse users 16

17 Side Effects Avoid modifying static objects Example: don't print error messages to System.out: if (newmessages.isfull()) System.out.println("Sorry--no space"); Your classes may need to run in an environment without System.out; throw exception instead 17

18 Analyzing Quality of Class Interface Customers: Programmers using the class Criteria: Cohesion Completeness Convenience Clarity Consistency Engineering activity: make tradeoffs 18

19 Cohesion Class describes a single abstraction Methods should be related to the single abstraction If a class has unrelated responsibilities, split it up 19

20 Completeness Support all operations that are well-defined on abstraction Potentially bad example: Date Date start = new Date(); // do some work Date end = new Date(); How many milliseconds have elapsed? - No such operation in Date class Does it fall outside the responsibility? 20

21 Convenience A good interface makes all tasks possible, and common tasks simple Bad example: Reading from System.in Why doesn't System.in have a readline method analogous to System.out.println? Why can't I make a BufferedReader from an input stream when I can make a PrintWriter from an output stream? 21

22 Consistency Related features of a class should have matching: names parameters return values behavior Bad example: new GregorianCalendar(year, month - 1, day) Why is month 0-based? 22

23 Clarity Client programmers need to be able to comprehend your class s interface: confused programmers write buggy code Clarity often comes down to documentation: explain what a method does in terms you (and your clients) can easily understand 23

24 Programming by Contract Spell out responsibilities: of caller of implementor Increase reliability Increase efficiency 24

25 Preconditions Excessive error checking is costly Returning dummy values can complicate testing Contract metaphor Service provider must specify preconditions If precondition is fulfilled, service provider must work correctly Otherwise, service provider can do anything 25

26 Preconditions When precondition fails, service provider may throw exception return false answer corrupt data 26

27 Assertions Mechanism for warning programmers; can be turned off after testing Syntax: assert condition; //note: no parentheses assert condition : explanation; Throws AssertionError if condition false and checking enabled During testing, run with java -enableassertions MyProg 27

28 Exceptions in the contract Exception throw part of the contract Caller can rely on behavior Exception throw not result of precondition violation This method has no precondition 28

29 Example IllegalArgumentException if queue is empty */ public Message removefirst() { if (count == 0) throw new IllegalArgumentException(); Message r = elements[head];... } 29

30 Postconditions Conditions that the service provider guarantees Every method promises Sometimes, can assert additional useful condition 30

31 Class Invariants Condition that is true after every constructor (no invalid objects can be created) preserved by every method (if it's true before the call, it's again true afterwards) Useful for checking validity of operations 31

32 Class invariants As long as instance fields are private, you have complete control over object modification Can guarantee certain values are within legal range, certain references are not null Invariant is appropriate tool for documenting such a guarantee 32

33 Interface vs. Implementation Invariants Interface invariants are conditions that involve only public interface of class of interest to class user give behavior guarantee for class objects Implementation invariants involve details of particular implementation of interest to class implementor can be used to ensure implementation correctness 33