1

Design Patterns in JavaPart IV

Operation PatternsChapter 20

Introducing Operations

Summary prepared by Kirk Scott

2

• This introductory chapter on operations is largely about terminology

• In order to talk clearly about operations and the operation design patterns it is necessary to define the term operation

• Part of defining the term includes explaining its relationship to and distinguishing it from the terms method, algorithm, and polymorphism

3

Operations and Methods

• It is helpful to remember that the term operation comes from UML

• Operation is a design term, not specifically an implementation term

• An operation is a design specification of a service that can be requested from an instance of a class

4

• Method is an implementation term• A method is an implementation of an

operation (for a given class)• Another way of pointing out the distinction

between operation and method is to say that operation is a level of abstraction higher than method

5

• An operation defines something that a class does and it also specifies the calling interface for this service

• However, different classes may implement the operation

• The specific methods for the different classes may themselves differ

6

• The differences in implementations are not necessarily due to obscure differences between the classes

• They may be the direct result of what the operation means when applied to those classes

• The book uses the toString() method as an example

7

• Each different class will have a different implementation of the toString() method

• This is unremarkable and normal• This is because the operation specification is

at a level of abstraction that says something like, “Return a string with the class name and its instance variables and values.”

8

• The book makes the following useful observation:

• Just as operations are at level more abstract than methods (implementations), design patterns themselves are at a level more abstract than classes and their methods

9

• It should not be surprising, when doing design work, to find that specifications of design patterns can be most conveniently given in terms of operations, not classes and methods

• Design patterns and operations are at roughly the same level of abstraction

10

• Think back to the Composite design pattern• In general, this pattern made it possible to

apply the same kind of operation to both individual items and groups of items

• In the examples given, it was of interest perform a count or check to see whether something was a tree

11

• You may recall that there was some mild cleverness in the way the methods were set up to accomplish these goals

• The point is that the general goals, count or check for a tree, are expressions of operations

• The implementation of the goals was the trickery involving multiple method declarations and implementations at different levels in the pattern

12

• Challenge 20.1• Use the words operation and method to

explain how Chain of Responsibility implements an operation.

13

• Solution 20.1• Chain of Responsibility distributes an

operation across a chain of objects.• Each method implements the operation’s

service directly or forwards calls to the next object in the chain.

14

• Comment mode on:• You could rewrite the previous description

substituting a word like functionality for operation

• The meaning would still be clear, but somewhat less precise

• The point of the challenge is simply to illustrate the proper use of the authors’ preferred terminology

15

• The next step in trying to be precise about terminology involves the declaration of methods

• Overall, the declaration/specification of a method consists of two parts:

• Header• body

16

• It’s clear what the body is:• It’s the code between the opening and closing

braces• It is the implementation• The header, can be broken down into four

different parts:• Modifiers, return type, signature, and throws

clause

17

• I tend to be careless when referring to the signature of a method

• Notice that technically it only consists of the name of the method and the parameter list that goes with it

• Why it was named the signature becomes clear• It is the name and parameter list which

distinguishes which method is intended when a method call is made

18

• What the return type represents should be clear

• Also, there should be no mysteries about the throws clause

• That leaves the topic of modifiers

19

• It turns out that this is kind of a grab bag• There are access modifiers, but if you think

about it, there have been other kinds of terms that occupy this position in a method declaration

• The following challenge is a handy review of what you already know, along with a few additional details (which are not of great importance)

20

• Challenge 20.2• Write down as many of the nine Java method

modifiers as you can.

21

• Solution 20.2• A complete list of Java method modifiers, with

informal definitions of their meanings, follows:• public: access permitted to all clients• protected: access permitted within the

declaring package and to subclasses of the class

22

• private: access permitted only within the class• abstract: no implementation provided• static: associated with the class as a whole,

not with individual objects• final: not allowed to be overridden• synchronized: method acquires access to the

object monitor or to the class’s, if the method is static

23

• native: implemented somewhere else in platform-dependent code

• strictfp: double and float expressions evaluated according to FP-strict rules, thus requiring intermediate results to be valid according to IEEE standards

24

• Solution 20.2, continued:• Although some developers might be tempted

to explore using all these modifiers in a single method definition, several rules limit the ability to use them in combination.

• Section 8.4.3 of the Java Language Specification [Gosling et al. 2005] lists these limitations

25

• Comment mode on:• One limitation is obvious: A method couldn’t

be both public and private at the same time, for example

• I would also add the following:• If you’re going to list the nine different

keywords, it would also be helpful to mention what happens without an access modifier

26

• If a method is declared without an access modifier, by default, it has package access

• The following observation is slightly off the topic, but also worth remembering

• Local variables in methods aren’t typically given access modifiers

• Their scope is the body of the method

27

Signatures

• The book points out that in a sense, the meaning of operation and signature are similar

• They both specify the interface by which a service, or method is called

• Of course, operation is more general, because it refers to the functionality as well as the interface alone

28

• The book quotes the Java language specification again:

• “The signature of a method consists of the name of the method and the number and types of formal parameters to the method.”

• Recall that the names of the parameters are not important to sorting out which method is in question

• On the other hand, the order of the different types of parameters makes a difference

29

• The book emphasizes that the signature doesn’t include the return type

• On the other hand, it notes that in general, if you override a method and change the return type, you’ll get a compiler error

• In the answer to the following challenge it backs off from the foregoing statement by mentioning covariant return types, which come up in CS 202

30

• Challenge 20.3• The method Bitmap.clone() returns Object,

even though the method always returns an instance of the Bitmap class.

• Would it still compile if its return type were declared as a Bitmap?

31

• Solution 20.3• It depends.• For pre-Java 5 versions: If you were to

somehow change the return value of Bitmap.clone(), the code wouldn’t compile.

• The clone() signature matches the signature of Object.clone(), so the return type must match as well.

32

• In Java 5: The language definition has changed to allow covariant return types, whereby a subclass can declare a more specific return type.

33

• The authors reiterate that operation and signature are related terms

• If you talk about several different classes sharing an operation, you expect that the method that implements that operation will have the same name and the same parameter list for the different classes

• In other words, the methods will have the same signature

34

• As soon as you are specifically interested in the name and parameter list and the syntactical rules for which method or version of a method is being called given a particular name and parameter list, then you are talking about the signature

• Operation is conceptually abstract• Signature is more concrete

35

• When referring to the operation, you’re interested in the functionality being implemented

• When referring to the signature, you’re interested in the syntactical specifics of the implementation

36

Exceptions

• Recall that a method header can end with a throws clause

• This indicates that under certain error conditions, the method throws an exception back to whatever client code called it

• It is then necessary for the client to make the call in a try/catch block in order to catch an exception if it’s thrown

37

• The previous statement was a bit of a simplification

• The client code may also choose to throw the exception rather than handling it

• The hierarchy of calls that throw the exception may be arbitrarily deep

38

• However, ultimately the code has to catch and handle the exception

• The book states that not catching the exception results in a run-time crash

• It seems to me that the compiler keeps track of this, and typically, code that doesn’t catch an exception will trigger a compiler error before a run-time problem can result

39

• Note that in the previous chapter the book showed a call to clone() without a try/catch block.

• I had the feeling then that the compiler would flag that.

• Once again it’s hard to say whether I’m confused or whether the authors are confused, or channeling the spirit of reformed C++ programmers

40

• It may be helpful to note that the try/catch structure is similar to a built-in if/else structure

• If a call is made and no exception is thrown, execution continues normally—and the catch block is ignored

• If an exception is thrown, then the code in the catch block is executed—or execution of the current method stops at that point and the exception is thrown to whatever method called it

41

• For beginning programmers, you typically are worried about catching exceptions that are thrown by system defined methods

• It is worth noting that you can also define your own exceptions and specifically write your own methods to originate and throw exceptions under error conditions

• The Java syntax for this is illustrated by this line of code:

• throw new Exception(“Good Luck!”);

42

• You may recall that in Java there are checked exceptions and unchecked exceptions

• I can never remember which is which by name, but this is the idea:

43

• There are some mistakes which programmers are responsible for which are not dealt with by the exception handling mechanism

• An example is dividing by 0• This doesn’t generate an exception• It will cause a run-time error

44

• There are other error conditions that programmers aren’t responsible for

• The classic example is problems when doing file operations

• If a program can’t open, write to, or read from a file, this may not be the program’s fault

45

• If a failure occurs, the program will be notified by means of an exception, and it should try to handle the condition

• The idea is not to burden the programmer with solving problems that are not the programmer’s fault

• The idea is to give the programmer a chance to successfully deal with problems that arise external to the program

46

• The book points out the following concerning the main competitors of Java:

• C# doesn’t require methods to declare exceptions

• C++ allows exception specifications to appear, but doesn’t require the compiler to check them

• Note that what these statements mean is not entirely clear

• The next challenge addresses them further

47

• Challenge 20.4• Unlike Java, C# does not require methods to

declare any exceptions that they might throw. Write down your opinion of whether this is an improvement on Java’s rules.

48

• Solution 20.4• One argument for leaving exception declarations out of

method headers:• We should first note that even Java does not require

methods to declare all the exceptions that might be thrown.

• Any method might, for example, encounter a null pointer and throw an undeclared exception.

• [This is the equivalent of dividing by 0 mentioned above—It’s the result of a mistake made by the programmer.]

49

• It’s impractical, as Java admits, to force programmers to declare all possible exceptions.

• Applications need a strategy for handling all exceptions.

• Requiring developers to declare certain types of exceptions is no substitute for architecting in an exception-handling policy.

50

• On the other hand:• Programmers need all the help they can get.• It’s true that an application architecture needs

to have a solid exception-handling strategy.• It’s also clearly impractical to force developers

to declare in every method the possibility of pervasive problems, such as null pointers.

51

• But for some errors, such as problems in opening a file, requiring the caller of a method to handle possible exceptions is a useful reminder.

• C# throws out the baby with the bathwater by removing any declaration of possible exceptions from method headers.

52

• Comment mode on:• The book seems to be touching on multiple,

related topics• First of all, it is clear that the discussion has to

do with checked and unchecked exceptions• In the book’s terminology, it’s a question of

declared and undeclared exceptions

53

• Secondly, the book seems to be concerned about one syntactical question—whether the a method is declared to throw an exception in its header

• Since I don’t know C#, the distinction they’re making is not clear, but I would observe the following:

• In Java, declaring “throws” in the header makes it possible to pass the exception back to a calling client, if desired

54

• There is a second syntactical element which the book doesn’t broach, and which I can’t say much about, again because I don’t know C#

• However, of equal importance to the declaration in the header is the need to use a try/catch block when calling a method that throws an exception

• We know that this is necessary in Java• Does such a structure exist in C#?

55

• Coming around full circle, the real question is whether this structure is of value

• In the second half of their answer the authors give the Java point of view

• Yes, all exceptions of any kind have to be handled somehow, and the programmer is reliant on the system and language for how this is done

56

• It is unreasonable to declare every possible exception

• Likewise, it’s unreasonable to put every statement that could generate an exception in a try/catch block

57

• On the other hand, surely there are cases where writing exception handling into programmer written code can be helpful

• Java takes the middle path of creating a structure for this and requiring it in certain well-defined cases

• This allows programmer written code to gracefully handle certain kinds of error conditions that it may encounter

58

• Java also makes it possible for programmers to use the same structure to deal with error conditions that the code itself might generate

• This is how come it is possible to construct an instance of an exception in the body of a method and to declare the method to throw it

• By the way, it is also possible to extend the Exception class and make application specific exceptions

59

Algorithms and Polymorphism

• In this section the authors return to trying to straighten out thinking about programming by being precise in the terminology used

• The book tackles the definition of an algorithm first

• It takes the definition given on the next overhead from Cormen, Leiserson, and Rivest

60

• “An algorithm is any well-defined computation procedure that takes some value, or set of values, as input and produces some value, or set of values, as output.”

• The point is that there is no set relationship between algorithms and methods

• One method may contain within it the implementations of more than one algorithm

61

• One method may also consist of the implementation of a single algorithm

• Finally, the implementation of a complex algorithm may consist of more than one method in some sort of relationship

• The book goes back to the Composite design pattern to illustrate the last point

62

• It takes four different isTree() methods, one abstract and three concrete in order to implement the algorithm for determining whether an instance of MachineComponent is a tree

• The UML diagram for the Composite design pattern with the methods is shown on the next overhead

63

64

• Challenge 20.5• How many algorithms, how many operations,

and how many methods does Figure 20.1 depict?

65

• The figure shows one algorithm—the procedure to determine whether an object model is a tree—two operations—appearing as two signatures in the MachineComponent class—and four methods.

66

• The title of this section of the chapter included the word polymorphism

• The point the book wants to make is that this example of multiple methods for one algorithm is based on polymorphism

• Many methods are involved because >1 class is involved and each different class can have a different implementation of a method with a given signature

• Which method implementation is used depends on which kind of object it’s called on

67

• It is worth noting that in a more traditional structured environment, as well as in a polymorphic environment, there is another way in which an algorithm could depend on >1 method

• If the algorithm is sufficiently complex, it would simply be broken down into subroutines or sub-methods

68

Summary

• This chapter is a preview to the chapters that give operations based design patterns

• The goal of the chapter was to clarify the terminology of operation, method, signature, and algorithm

• An operation is an abstract specification of a service

• Such a service may be provided by >1 method with the same signature

69

• The term signature is refers to the name and parameters of a method and the rules for determining which method to use based on these characteristics

• A method definition includes modifiers, a return type, a signature, and potentially a throws clause

• A method implements an operation• A method may run successfully to completion, or

it may encounter an exception

70

• An algorithm is a set of steps for performing some computation

• An algorithm may be “smaller than”, “the same size as”, or “larger than” a single method

• When an algorithm involves >1 method, this may be the result of multiple classes and polymorphism in the design pattern

• Note: As usual, with an introductory chapter, more stuff follows the summary

71

Beyond Ordinary Operations

• The table shown on the next overhead previews the five operation design patterns

• As usual, it’s not really clear what the explanations mean until you see the patterns in greater detail

72

73

• As you might expect, the operation design patterns are cases more complicated that one operation = one method = one algorithm

• The book summarizes the preview in this way:• The operation design patterns tend to have

more than one method, usually with the same signature, participating in a design

74

The End