Design Patterns in Java Part IV Operation Patterns Chapter 20 Introducing Operations

1. Design Patterns in JavaPart IVOperation PatternsChapter 20Introducing 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.