Section 4.1. What Is a Class?

4.1. What Is a Class?

Like any new concept, when first coming to grips with what classes are, it's usually helpful to start with an analogy. The analogy we'll use here is that of guitars, and my favorite guitar is the Burns Brian May Signature (BMS) guitar, shown in Figure 4-2.

Figure 4-2. One of my guitars: a good example of an object

The guitar in Figure 4-2 is an example of an object. It has an identity: it's the one I own. However, I'm not going to pretend that Burns made only one of this type of guitar and that it was just for meI'm not that good a guitarist! Burns as a company will make hundreds of this type of guitar or, to put it another way, this class of guitar.

A class is a type of something. You can think of a class as being the blueprint out of which objects can be constructed, as shown in Figure 4-3.

Figure 4-3. The class defines the main characteristics of the guitar; using the class, any number of guitar objects can be constructed

In this analogy, the BMS guitar that Burns manufactures is an example of a class of guitar. Burns know how to build this type of guitar from scratch based on its blueprints. Each guitar constructed from the class can be referred to as an instance or object of the class, and so my guitar in Figure 4-2 is an instance of the Burns BMS Guitar class.

At its simplest, a class's description will include two pieces of information: the state information that objects of the class will contain and the behavior that they will support. This is what differentiates OO from other forms of system development. In OO, closely related state and behavior are combined into class definitions, which are then used as the blueprints from which objects can be created.

In the case of the Burns BMS Guitar class, the class's state could include information about how many strings the guitar has and what condition the guitar is in. Those pieces of information are the class's attributes .

To complete the description, we need to know what the guitar can do. This includes behavior such as tuning and playing the guitar. A class's behavior is described as the different operations that it supports.

Attributes and operations are the mainstays of a class's description (see "Class State: Attributes"). Together, they enable a class to describe a group of parts within your system that share common characteristics such as staterepresented by the class's attributesand behaviorrepresented by the class's operations (see "Class Behavior: Operations" later in this chapter).

4.1.1. Abstraction

A class's definition contains the details about that class that are important to you and the system you are modeling. For example, my BMS guitar might have a scratch on the backor severalbut if I am creating a class that will represent BMS guitars, do I need to add attributes that contain details about scratches? I might if the class were to be used in a repair shop; however, if the class were to be used only in the factory system, then scratches are one detail that I can hopefully ignore. Discarding irrelevant details within a given context is called abstraction.

Let's have a look at an example of how a class's abstraction changes depending on its context. If Burns were creating a model of its guitar production system, then it would probably be interested in creating a Burns BMS Guitar class that models how one is constructed, what materials are to be used, and how the guitar is to be tested. In contrast, if a Guitar World store were creating a model of its sales system, then the Burns BMS Guitar class might contain only relevant information, such as a serial number, price, and possibly any special handling instructions.

Getting the right level of abstraction for your model, or even just for a class, is often a real challenge. Focus on the information that your system needs to know rather than becoming bogged down with details that may be irrelevant to your system. You will then have a good starting point when designing your system's classes.

Abstraction is key not only to class diagrams but to modeling in general. A model, by definition, is an abstraction of the system that it represents. The actual system is the real thing; the model contains only enough information to be an accurate representation of the actual system. In most cases, the model abstracts away details that are not important to the accuracy of the representation.

4.1.2. Encapsulation

Before we take a more detailed look at attributes, operations, and how classes can work together, it's worth focusing on what is the most important characteristic of classes and object orientation: encapsulation .

According to the object-oriented approach to system development, for an object to be an object, it needs to contain both dataattributesand the instructions that affect the dataoperations. This is the big difference between object orientation and other approaches to system development: in OO, there is the concept of an object that contains, or encapsulates, both the data and the operations that work on that data.

Referring back to the guitar analogy, the Burns BMS Guitar class could encapsulate its strings, its body, its neck, and probably some neat electrics that no one should mess around with. These parts of the guitar are effectively its attributes, and some of the attributes, such as the strings, are accessible to the outside world and others, such as electrics, are hidden away. In addition to these attributes, the Burns BMS Guitar class will contain some operations that will allow the outside world to work with the guitar's attributes. At a minimum, the guitar class should at least have an operation called play so that the guitar objects can be played, but other operations such as clean and possibly even serviceElectrics may also be encapsulated and offered by the class.

Encapsulation of operations and data within an object is probably the single most powerful and useful part of the object-oriented approach to system design. Encapsulation enables a class to hide the inner details of how it works from the outside worldlike the electrics from the example guitar classand only expose the operations and data that it chooses to make accessible.

Encapsulation is very important because with it, a class can change the way it works internally and as long as those internals are not visible to the rest of the system, those changes will have no effect on how the class is interacted with. This is a useful feature of the object-oriented approach because with the right classes, small changes to how those classes work internally shouldn't cause your system to break.