Section 4.5. Class Behavior: Operations

4.5. Class Behavior: Operations

A class's operations describe what a class can do but not necessarily how it is going to do it. An operation is more like a promise or a minimal contract that declares that a class will contain some behavior that does what the operation says it will do. The collection of all the operations that a class contains should totally encompass all of the behavior that the class contains, including all the work that maintains the class's attributes and possibly some additional behavior that is closely associated with the class.

Operations in UML are specified on a class diagram with a signature that is at minimum made up of a visibility property, a name, a pair of parentheses in which any parameters that are needed for the operation to do its job can be supplied, and a return type, as shown in Figure 4-16.

Figure 4-16. Adding a new operation to a class allows other classes to add a BlogEntry to a BlogAccount

In Figure 4-16, the addEntry operation is declared as public; it does not require any parameters to be passed to it (yet), and it does not return any values. Although this is a perfectly valid operation in UML, it is not even close to being finished yet. The operation is supposed to add a new BlogEntry to a BlogAccount, but at the moment, there is no way of knowing what entry to actually add.

4.5.1. Parameters

Parameters are used to specify the information provided to an operation to allow it to complete its job. For example, the addEntry(..) operation needs to be supplied with the BlogEntry that is to be added to the account, as shown in Figure 4-17.

Figure 4-17. Adding a new parameter to the addEntry operation saves a bit of embarrassment when it comes to implementing this class; at least the addEntry operation will now know which entry to add to the blog!

The newEntry parameter that is passed to the addEntry operation in Figure 4-17 shows a simple example of a parameter being passed to an operation. At a minimum, a parameter needs to have its type specifiedin this case, BlogEntry class. More than one parameter can be passed to an operation by splitting the parameters with a comma, as shown in Figure 4-18. For more information on all the nuances of parameter notation, see UML 2.0 in a Nutshell (O'Reilly).

Figure 4-18. As well as passing the new blog entry that is to be added, by adding another parameter, we can also indicate which author wrote the entry

4.5.2. Return Types

As well as a name and parameters, an operation's signature also contains a return type. A return type is specified after a colon at the end of an operation's signature and specifies the type of object that will be returned by the operation, as shown in Figure 4-19.

There is one exception where you don't need to specify a return type: when you are declaring a class's constructor. A constructor creates and returns a new instance of the class that it is specified in, therefore, it does not need to explicitly declare any return type, as shown in Figure 4-20.

Figure 4-19. The addEntry(..) operation now returns a Boolean indicating whether the entry was successfully added

Figure 4-20. The BlogAccount(..) constructor must always return an instance of BlogAccount, so there is no need to explicitly show a return type