Attributes and methods from a description

By the end of this you will be able to read a description of a problem and pick out the attributes and the methods one class needs.

In the last lesson, a parcel had two attributes: a town and a weight. Objects can also do things. Something an object can do is a method. A class lists both: the attributes say what each object keeps, and the methods say what each object can do.

Before any code is written, someone has to decide what goes in the class. Here is a way to do that. Read the description one phrase at a time, and ask two questions of each phrase, in this order.

Do this for every phrase in the description. A phrase that is neither a value each object keeps nor something it does is left out of the class.

Here is the description a city gives a programmer. "A city sells bus passes. Each pass has a code printed on it, such as P2041, and a balance in cents. A rider can top up a pass with any amount. Each trip takes the fare off the balance, but only if the balance is big enough to pay it. The city's name is shown at the top of the screen, and the screen can show the balance of any pass."

Going through it phrase by phrase:

• "a code printed on it": every pass has its own code, so the code is an attribute. It holds letters, so it is text.
• "a balance in cents": every pass has its own balance, so it is an attribute, a whole number of cents.
• "top up a pass with any amount": this is something a pass does, so it is a method. It needs one value from outside the pass: the amount.
• "takes the fare off the balance, but only if": also something a pass does, a method. It needs the fare, and it reads the balance to decide whether the trip can go ahead.
• "show the balance of any pass": a method that gives back the balance.
• "the city's name": this is the same for every pass, and it is not about any one pass, so it is not an attribute of a pass. It belongs somewhere else in the program.
• "a rider": the rider is a person, not a value the pass keeps. Leave it out unless the description says the pass must remember who owns it.

So the class BusPass needs:

• attributes: the code (text) and the balance (a whole number of cents);
• methods: top up (given an amount), pay a fare (given the fare), and show the balance.

An attribute is usually named by a noun in the description, and it holds a value. Each object has its own copy, so two passes can have different balances. Ask: does each object need to remember this between one moment and the next?

A method is usually named by a verb, because it is an action. It usually reads or changes the object's own attributes. Topping up changes the balance. Paying a fare reads the balance and may change it. Showing the balance only reads it. Ask: is this something the object does, or something done to it?

A method can need values from outside the object, given each time it is used, such as the amount to top up. Those values are not attributes, because the pass does not keep them after the top-up is done. Only the new balance is kept.

Some attributes are not named in the description as values. Look at the rules instead. Suppose the city adds one more rule: "every tenth trip on a pass is free". The rule names no value, but a pass can only tell that a trip is its tenth if it has counted its trips so far. So BusPass would need one more attribute: a count of trips, a whole number that goes up by one on every trip. If a rule says an object must behave differently later because of something that happened earlier, the object needs an attribute to remember it.

• Making an action an attribute, such as an attribute called "top up". Top up is something a pass does, so it is a method.
• Making something that is shared by every object an attribute, such as the city's name. It would be copied into every pass, and changing it would mean changing every pass.

Lessons 8.4 and 8.5 turn a design like this into code. Lesson 8.3 shows how to draw a design like this as a UML class box.

Now try it yourself on the questions below.