OOP 04

• One important factor in determining the “Programs must be written for people to read, and only incidentally for machines to execute.” NNL – Khoa Toán Tin ĐHKHTN 5 CODING STYLES AND NAM

Trang 1

CHAPTER 4

Elegance and Methods

Contents

• INTRODUCTION

• CODING STYLES AND NAMING CONVENTIONS

• METHODS AND DECOMPOSITION

• This chapter focuses mostly on

implementation and specificationissues

Trang 2

• More precisely, this chapter discusses

standard forms for methods and elegant

implementations of methods

• One important factor in determining the

“Programs must be written for people to read,

and only incidentally for machines to execute.”

NNL – Khoa Toán Tin ĐHKHTN 5

CODING STYLES AND NAMING CONVENTIONS

• There are many coding styles for writing the bodies of classes and their methods using Java

• However, there are valid reasons for following certain agreed-upon stylistic conventions as much as possible

• Sun Microsystems suggests certain conventions when writing Java programs

(http://java.sun.com/docs/codeconv/)

Guidelines

Choose a standard coding style and follow

that style throughout all your code

• One of the most important coding conventions affecting readability and

variables, classes, and methods

• Classes and interfaces should have names that reflect the role or intention of the objects

of those types Interfaces often have names ending in “able” or “ible”

Trang 3

• The method name should indicate the intent

of the method, that is, what the method is

supposed to accomplish The name should

not indicate how the method accomplishes

its goal but rather what that goal is

• Variables need to be named appropriately to

promote readability (Ex: nT,

theNumberOfThreadsInTheCurrentApplicatio

nRunningRightNow.)

• Using good names is even more important for constants

• Finally, not only is choosing the right names important, but also following convention in the capitalization of the names is important

• Follow a consistent capitalization scheme, starting your class and interface names with capital letters and starting your variable and method names with small letters

Guideline

Use intention-revealing names for all

variables, methods, and classes so that they

accurately describe the role or intentions of

the things they are naming

METHODS AND DECOMPOSITION

• Programmers can treat methods as if they were built-in higher-level features in the programming language, and so they can conceptualize larger sections of code

• The process of breaking code into methods is called functional decomposition

• The decomposition of code into well-designed methods not only improves the readability of the code, it also promotes reusability

Trang 4

• When should a method be decomposed into

other methods?

• Decomposition should also be considered

when there is duplicate code

• Consider some examples

public void parse(String expression) {

// do some parsing

if( ! nextToken.equals("+") ) { //error System.out.println("Expected +, but found " + nextToken); System.exit(1);

} if( ! nextToken.equals("*") ) { //error System.out.println("Expected *, but found " + nextToken); System.exit(1);

}

public void parse(String expression)

public class Family {

public Family(Person father, Person mother, Person[] children) {

code

} public Family(Person father, Person mother) {

this(father, mother, new Person[0]);

} other methods

}

Trang 5

Guideline

Use methods, especially private auxiliary

methods, for decomposition to reduce

duplication of code and to raise the level of

abstraction of the code

}

Trang 6

COHESIVE METHODS

• There is another implication to the statement

that a method should do one thing only The

implication is that a method should not both

return a value and modify the state of some

object (Command-Query Separation Principle)

• (Some standard methods in the Java library

classes that do not follow this guideline.)

COHESIVE METHODS

GuidelineFunctions (which return a value) should not modify any existing object’s state in a way visible to other objects and modifier methods (which modify one or more objects’ state) should have “void” as the return type

Trang 7

• Consider a MyLinkedList class that has an

instance variable head of type Node and

another instance variable length of type int

WELL-FORMED OBJECTS AND CLASS INVARIANTS

• Consider what would happen if the value of length was different than the actual number

of nodes

• Clearly, we need the two values (length and the number of nodes) to be the same if the class is to be usable

• It is this kind of internal consistency that we

WELL-FORMED OBJECTS

AND CLASS INVARIANTS

• A good way is to specify what makes objects of a

class well-formed is to list the class invariants

• A class invariant is a statement about the state of

objects of the class between public method calls.

• The statement of equality of the value of length

and the number of Nodes in an object of the

MyLinkedList class is an example of a class

invariant.

WELL-FORMED OBJECTS AND CLASS INVARIANTS

• Is it a good idea to have such a length instance variable, as we described above? After all, you can compute the length of the list whenever you want by traversing it and counting the number of nodes

Trang 8

WELL-FORMED OBJECTS

AND CLASS INVARIANTS

Guideline

Be aware that, although it can increase the

efficiency of your code, caching values instead

of computing them when they are needed can

also increase the complexity and number of

invariants of your class

INTERNAL DOCUMENTATION

• A software package, no matter how well designed otherwise, is almost worthless if documentation is not included

• Internal documentation is the documentation for someone who is looking at the source code

• Internal documentation should also clearly state any class or method invariants that exist

• Internal documentation should not repeat

what the code says Instead, it should

summarize the intent or purpose of the code

or gives a higher-level explanation

• Internal documentation mostly consists of

comments in the source code, but the code

itself can be a useful part of the

documentation if the code is well written

GuidelineAlways strive for “self-documenting code” that is so clear that no comments are necessary

• Code needing a large number of comments usually indicates poor code

Trang 9

Guideline

If your code is so complicated that it needs

explaining with lots of internal or external

documentation, then the code should

2 If documentation does not agree with the code,

it is not worth much.

3 Consequently, code must largely document itself

If it cannot, rewrite the code rather than increase the supplementary documentation Good code needs fewer comments than bad code does.

4 Comments should provide additional information that is not readily obtainable from the code itself They should never parrot the code.

5 Mnemonic variable names and labels, and a layout that emphasizes logical structure, help make a program self-documenting.

Trang 10

EXTERNAL DOCUMENTATION

• External documentation is for the users of the

code who can’t look at or don’t care about the

source code itself

• It describes the public classes, interfaces,

methods, fields, and packages and how to use

them

• External documentation might also include

design documents such as UML diagrams

• What should be included in external

documentation?

• One of the important steps in the design

process is the development of a precise

specification of the behavior of the method

before the method is implemented

• This specification is useful to the designer so

that he or she can document exactly the role

the method will play in the system

Trang 11

• Here is an example of more complete

documentation for the nthRoot method:

public double nthRoot(double value, int n)

returns the n-th root of the double value.

If n is even, the positive n-th root is returned.

If n is odd, the n-th root will have the same sign

public static Set intersect(Set s1, Set s2) returns a Set with the common elements of s1 and s2 by first creating an empty Set to be filled with the common elements and then stepping through the elements of s1 using an iterator and testing whether those elements are also in s2 by calling s2.contains(e), where e is the next element of s1 to be tested If s2 contains e, then e is added to the Set that is returned.

Guideline

The external documentation for a method

should be sufficiently specific to exclude

implementations that are unacceptable but

sufficiently general to allow all

implementations that are acceptable

• How do you determine when the external documentation for a method is just right?

• Think of a method as a service: specify clearly

object will do in return when it executes the method

• In terms of a contract: If a user provides appropriate arguments, then your method promises to perform a specific service

Trang 12

• A precondition is a condition that must be true

tells what the method guarantees will happen

when it is executed

• It is up to the client to make sure the

preconditions are satisfied before attempting

the method call

GuidelineSpecify precisely all preconditions and postconditions for each of your methods in the external documentation These conditions form the contract for your method

Example:

Better external documentation would warn the

user that the two parameters must not be null:

public static Set intersect(Set s1, Set s2)

Precondition: s1 and s2 are not null.

Postcondition: returns a Set with the

common elements of s1 and s2.

Trang 13

Guideline

Try to make your methods do something

appropriate in all cases so that there are no

preconditions

• This guideline is one example of a practice

called defensive programming

• There are situations where this guideline

needs to be ignored

Guideline (Liskov Substitution Principle)

It is acceptable to make B a subclass of A only

if for every public method with identical signatures in both A and B, the preconditions for B’s method are no stronger than the preconditions for A’s method and the postconditions for B’s method are no weaker than the postconditions for A’s method

CASE STUDY: OVERRIDING THE EQUALS

METHOD IN JAVA

• Suppose you have created a new class and

have decided to override the equals(Object)

method inherited from the Object class or

another superclass

• You can’t, of course, change the method

arbitrarily and still expect to have an elegant

1 It is reflexive: for any nonnull reference value x, x.equals(x) should return true.

2 It is symmetric: for any nonnull reference values

x and y, x.equals(y) should return true if and only

if y.equals(x) returns true.

Trang 14

METHOD IN JAVA

3 It is transitive: for any nonnull reference values x,

y, and z, if x.equals(y) returns true and y.equals(z)

returns true, then x.equals(z) should return true.

4 It is consistent: for any nonnull reference values x

and y, multiple invocations of x.equals(y)

consistently return true or consistently return

false, provided no information used in equals

comparisons on the object is modified.

5 For any nonnull reference value x, x.equals(null)

should return false.

• The implementation of the equals method in the Object class tests object identity.

• Some standard Java classes, such as String and Point, override this method to test equality in a different way.

OVERRIDING THE EQUALS METHOD IN

JAVA

public class Triangle {

private Point p1, p2, p3; //the three corners

public Triangle(Point p1, Point p2, Point p3) {

if( p1 == null ) p1 = new Point(0,0);

this.p1 = p1; this.p2 = p2; this.p3 = p3;

if( ! (obj instanceof Triangle) ) return false; Triangle otherTriangle = (Triangle) obj;

return (p1.equals(otherTriangle.p1) &&

p2.equals(otherTriangle.p2) &&

p3.equals(otherTriangle.p3));

}

Trang 15

METHOD IN JAVA

• Note how this method elegantly uses the

equals method of its components Does this

equals method implement an equivalence

relation?

Yes, it is

• Now let’s create a subclass of Triangle

}

ColoredTriange blueTriangle = new

ColoredTriangle(Color.blue, new Point(0,0), new Point(1,3), new Point(2,2));

System.out.println(redTriangle.equals(blueTr iangle));

System.out.println(blueTriangle.equals(redTr

Trang 16

METHOD IN JAVA

• It seems reasonable to implement the

ColoredTriangle’s equals method in a way

similar to the Triangle’s equals method:

METHOD IN JAVA

//version 1 — in ColoredTriangle class public boolean equals(Object obj) {

if( ! (obj instanceof ColoredTriangle) ) return false; ColoredTriangle otherColoredTriangle =

(ColoredTriangle) obj;

return super.equals(otherColoredTriangle) &&

this.color.equals(otherColoredTriangle.color);

}

• So we are done? Consider this test code:

METHOD IN JAVA

// Test code

Triangle t = new Triangle(new Point(0,0), new

Point(1,3), new Point(2,2));

ColoredTriangle rct = new ColoredTriangle(Color.red,

ColoredTriangle, then the method just calls and returns the result of the superclass’

(Triangle’s) equals method

Trang 17

METHOD IN JAVA

//version 2 — in ColoredTriangle class

public boolean equals(Object obj) {

if( obj instanceof ColoredTriangle ) {

ColoredTriangle otherColoredTriangle = (ColoredTriangle) obj;

return super.equals(otherColoredTriangle) &&

METHOD IN JAVA

//version 2 — in the Triangle class public boolean equals(Object obj) {

if( obj == null ) return false;

if( obj.getClass() != this.getClass() ) return false;

Triangle otherTriangle = (Triangle) obj;

return (p1.equals(otherTriangle.p1) &&

p2.equals(otherTriangle.p2) &&

p3.equals(otherTriangle.p3));

}

• The method now implements an equivalence relation ?

METHOD IN JAVA

//version 3 – in ColoredTriangle class

public boolean equals(Object obj)

{

if( obj == null ) return false;

if( obj.getClass() != this.getClass() ) return false;

if( ! super.equals(obj) ) return false;

• Suppose a user has three variables t1, t2, and t3 of type Triangle Consider:

t1.equals(t3)t2.equals(t3)

Định dạng
Số trang	23
Dung lượng	160,02 KB