IB Computer Science Topic B3.1.2: Designing Classes, Their Methods, and Behaviour Notes

Class Design Begins with the Requirements, Not the Code

1. A class design turns a written description of what a system must do into a set of attributes and methods before any code is written.
2. The attributes are the data the object must remember; the methods are what the object must be able to do.
3. Getting this wrong is expensive, because attributes chosen badly force every method built on them to be rewritten.
4. This statement asks you to construct a design, so you are marked on the design artefact, most often a UML class diagram.

Reading Requirements into a Class: The Noun-and-Verb Method

1. The method works because a requirements statement already names the entities and the actions in ordinary language.
2. Find the nouns and the recurring one becomes the class.
   1. "The library must record each book and whether it is on loan" gives a Book class.
3. Find the data each noun carries and those become the attributes.
   1. Title, author, ISBN and isOnLoan are all facts a single book must remember about itself.
   2. Anything the object can work out on demand is not an attribute; store dateOfBirth and calculate age from it.
4. Find the verbs applied to that noun and those become the methods.
   1. "Members can borrow and return books" gives lend() and returnBook().
5. Decide the data type of every attribute before drawing the diagram.
   1. isOnLoan is a boolean, not the string "yes", so the condition can be tested directly.
6. Decide what each method needs and gives back, which fixes its parameters and return type.
   1. lend() needs the member's ID and returns whether the loan succeeded.

UML Class Diagram Notation: Three Compartments

1. A UML class diagram shows a class as a box divided into three compartments, always in the same order.
2. The top compartment holds the class name, written in the singular with a capital letter.
   1. An abstract class name is written in italics, which you will meet in B3.2 at higher level.
3. The middle compartment holds the attributes, one per line.
4. The bottom compartment holds the methods, one per line.
   1. Constructors are written in the method compartment with the class name and no return type.
5. Leaving a compartment empty is allowed, but the compartment itself is still drawn.

Visibility Markers

Every attribute and method carries a symbol in front of it showing who can reach it.

1. In an encapsulated design, attributes are private and methods are public, so almost every attribute line starts with a minus sign.
2. A diagram whose attributes are all marked + is a design error, not a style choice, because it exposes the object's state.
3. Static members are shown underlined, which distinguishes a shared class variable from a per-object one.

Writing Attribute and Method Lines

1. The two line formats are fixed, and marks are given for using them exactly.
2. An attribute is written as visibility name: type, for example - roomNumber: int
3. A method is written as visibility name(parameter: type): returnType, for example + accelerate(amount: int): void
4. A method that returns nothing is marked void, and the brackets are written even when there are no parameters.
5. Where a default value matters it is added after the type, as in - isOccupied: boolean = false.

Relationship Lines Between Classes

1. Where a design has more than one class, the lines joining the boxes carry meaning of their own.
2. A plain line is an association, and a number or range at each end shows multiplicity, such as 1 or 0..*.
3. An open diamond at the owning end marks aggregation; a filled diamond marks composition.
4. A hollow triangle pointing at the superclass marks inheritance.

Turning the Design into Code

1. The diagram maps onto code line for line, which is why the design is worth finishing first.
2. The class name compartment becomes the class declaration.
   1. Each attribute line becomes a private instance variable of the stated type.
   2. The constructor line becomes the method that fills those variables at the moment the object is built.
   3. Each remaining method line becomes a method with the parameters and return type shown.
3. If a method in the diagram has no matching code, the design and the program have drifted apart.

Common Design Errors

1. Two errors account for most lost marks on this statement.
2. Storing what can be calculated. An age attribute goes stale every year; a dateOfBirth attribute does not.
3. Designing a class with only data. A class with attributes and no methods is a record, not a class, and gives up the behaviour half of OOP.