Representing Behavior and Structure

I l @ ve RuBoard

A class embodies a set of responsibilities that define the behavior of the objects in the class. The responsibilities are carried out by the operations defined for the class. An operation should do only one thing and it should do it well! For example, a CourseOffering class needs to be able to add a student and remove a student. These responsibilities are represented by two operations ”one that knows how to add a student and one that knows how to remove a student. All instances of the class will be able to perform the identified operations of the class.

The structure of an object is described by the attributes of the class. Each attribute is a data definition held by objects of the class. Objects defined for the class have a value for every attribute of the class. For example, a Course class has the attributes of name , definition, and number of credit hours. This implies that every Course object will have a value for each attribute. Attribute values do not have to be unique ”there are many three-credit courses in the university.

As with classes, style guides should be followed while defining attributes and operations. In this case study, attributes and operations start with a lowercase letter, and underscores are not used ” names composed of multiple words are pushed together and the first letter of each additional word is capitalized (e.g., numberOfStudents). Care should be taken to ensure that appropriate style guides are followed for all defined attributes and operations. This provides consistency across the classes, which leads to more readable and maintainable models and code.

If an object in a class does not need an attribute or operation, look at the class definition. This may be a sign that the class is not cohesive and should be broken up into separate classes. For example, suppose the CourseOffering class had the following attributes: offerNumber, location, timeOfDay, department, numberOfferingsInDepartment. A CourseOffering may care about its department but it probably does not care about the number of other offerings in the department. A better model would be a CourseOffering class related to a Department class. This is in keeping with the general rule that a class should have a major theme.

I l @ ve RuBoard