Techniques for Designing Classes

Tec echniques hniques ffor or Designing Cl Classes asses The Unified Modeling Language When designing a class, it is often helpful to draw a UML diagram. UML stands for Unified Modeling Language. It provides a set of standard diagrams for graphically depicting objectoriented systems. Figure 10-9 shows the general layout of a UML diagram for a class. Notice the diagram is a box that is divided into three sections. The top section is where you write the name of the class. The middle section holds a list of the class’s data attributes. The bottom section holds a list of the class’s methods. Following this layout, Figure 10-10 and 10-11 show UML diagrams for the Coin class and the CellPhone class that you saw previously in this chapter. Notice we did not show the self parameter in any of the methods, since it is understood that the self parameter is required. Figure 10-9 General layout of a UML diagram for a class Figure 10-10 UML diagram for the Coin class Figure 10-11 UML diagram for the CellPhone class Finding the Classes in a Problem When developing an object-oriented program, one of your first tasks is to identify the classes that you will need to create. Typically, your goal is to identify the different types of real-world objects that are present in the problem, then create classes for those types of objects within your application. Over the years, software professionals have developed numerous techniques for finding the classes in a given problem. One simple and popular technique involves the following steps: 1) Get a written description of the problem domain. 2) Identify all the nouns (including pronouns and noun phrases) in the description. Each of these is a potential class. 3) Refine the list to include only the classes that are relevant to the problem. Let’s take a closer look at each of these steps. Writing a Description of the Problem Domain The problem domain is the set of real-world objects, parties, and major events related to the problem. If you adequately understand the nature of the problem you are trying to solve, you can write a description of the problem domain yourself. If you do not thoroughly understand the nature of the problem, you should have an expert write the description for you. For example, suppose we are writing a program that the manager of Joe’s Automotive Shop will use to print service quotes for customers. Here is a description that an expert, perhaps Joe himself, might have written: Joe’s Automotive Shop services foreign cars and specializes in servicing cars made by Mercedes, Porsche, and BMW. When a customer brings a car to the shop, the manager gets the customer’s name, address, and telephone number. The manager then determines the make, model, and year of the car and gives the customer a service quote. The service quote shows the estimated parts charges, estimated labor charges, sales tax, and total estimated charges. The problem domain description should include any of the following: 1) Physical objects such as vehicles, machines, or products 2) Any role played by a person, such as manager, employee, customer, teacher, student, etc. 3) The results of a business event, such as a customer order, or in this case a service quote 4) Recordkeeping items, such as customer histories and payroll records Identify All of the Nouns The next step is to identify all of the nouns and noun phrases. (If the description contains pronouns, include them too.) Here’s another look at the previous problem domain description. This time the nouns and noun phrases appear in bold. Joe’s Automotive Shop services foreign cars and specializes in servicing cars made by Mercedes, Porsche, and BMW. When a customer brings a car to the shop, the manager gets the customer’s name, address, and telephone number. The manager then determines the make, model, and year of the car and gives the customer a service quote. The service quote shows the estimated parts charges, estimated labor charges, sales tax, and total estimated charges. Notice some of the nouns are repeated. The following list shows all of the nouns without duplicating any of them: address BMW car cars customer estimated labor charges estimated parts charges foreign cars Joe’s Automotive Shop make manager Mercedes model name Porsche sales tax service quote shop telephone number total estimated charges year Refining the List of Nouns The nouns that appear in the problem description are merely candidates to become classes. It might not be necessary to make classes for them all. The next step is to refine the list to include only the classes that are necessary to solve the particular problem at hand. We will look at the common reasons that a noun can be eliminated from the list of potential classes. 1) Some of the nouns really mean the same thing. In this example, the following sets of nouns refer to the same thing: car, cars, and foreign cars These all refer to the general concept of a car. Joe’s Automotive Shop and shop Both of these refer to the company “Joe’s Automotive Shop.” We can settle on a single class for each of these. In this example, we will arbitrarily eliminate cars and foreign cars from the list and use the word car. Likewise, we will eliminate Joe’s Automotive Shop from the list and use the word shop. The updated list of potential classes is: address BMW car cars customer estimated labor charges estimated parts charges foreign cars Joe’s Automotive Shop make manager Mercedes model name Porsche sales tax service quote shop telephone number total estimated charges year Because car, cars, and foreign cars mean the same thing in this problem, we have eliminated cars and foreign cars. Also, because Joe’s Automotive Shop and shop mean the same thing, we have eliminated Joe’s Automotive Shop. 2. Some nouns might represent items that we do not need to be concerned with in order to solve the problem. A quick review of the problem description reminds us of what our application should do: print a service quote. In this example, we can eliminate two unnecessary classes from the list: o We can cross shop off the list because our application only needs to be concerned with individual service quotes. It doesn’t need to work with or determine any company-wide information. If the problem description asked us to keep a total of all the service quotes, then it would make sense to have a class for the shop. o We will not need a class for the manager because the problem statement does not direct us to process any information about the manager. If there were multiple shop managers, and the problem description had asked us to record which manager generated each service quote, then it would make sense to have a class for the manager. The updated list of potential classes at this point is: address BMW car cars customer estimated labor charges estimated parts charges foreign cars Joe’s Automotive Shop make manager Mercedes model name Porsche sales tax service quote shop telephone number total estimated charges year Our problem description does not direct us to process any information about the shop, or any information about the manager, so we have eliminated those from the list. 3. Some of the nouns might represent objects, not classes. We can eliminate Mercedes, Porsche, and BMW as classes because, in this example, they all represent specific cars and can be considered instances of a car class. At this point, the updated list of potential classes is: address BMW car cars customer estimated labor charges estimated parts charges foreign cars Joe’s Automotive Shop make manager Mercedes model name Porsche sales tax service quote shop telephone number total estimated charges year We have eliminated Mercedes, Porsche, and BMW because they are all instances of a car class. That means that these nouns identify objects, not classes. NOTE: Some object-oriented designers take note of whether a noun is plural or singular. Sometimes a plural noun will indicate a class, and a singular noun will indicate an object. 4. Some of the nouns might represent simple values that can be assigned to a variable and do not require a class. Remember, a class contains data attributes and methods. Data attributes are related items that are stored in an object of the class and define the object’s state. Methods are actions or behaviors that can be performed by an object of the class. If a noun represents a type of item that would not have any identifiable data attributes or methods, then it can probably be eliminated from the list. To help determine whether a noun represents an item that would have data attributes and methods, ask the following questions about it: • Would you use a group of related values to represent the item’s state? • Are there any obvious actions to be performed by the item? If the answers to both of these questions are no, then the noun probably represents a value that can be stored in a simple variable. If we apply this test to each of the nouns that remain in our list, we can conclude that the following are probably not classes: address, estimated labor charges, estimated parts charges, make, model, name, sales tax, telephone number, total estimated charges, and year. These are all simple string or numeric values that can be stored in variables. Here is the updated list of potential classes: address BMW car cars customer estimated labor charges estimated parts charges foreign cars Joe’s Automotive Shop make manager Mercedes model name Porsche sales tax service quote shop telephone number total estimated charges year As you can see from the list, we have eliminated everything except car, customer, and service quote. This means that in our application, we will need classes to represent cars, customers, and service quotes. Ultimately, we will write a Car class, a Customer class, and a ServiceQuote class. Identifying a Class’s Responsibilities Once the classes have been identified, the next task is to identify each class’s responsibilities. A class’s responsibilities are: the things that the class is responsible for knowing. the actions that the class is responsible for doing. We have eliminated address, estimated labor charges, estimated parts charges, make, model, name, sales tax, telephone number, total estimated charges, and year as classes because they represent simple values that can be stored in variables. When you have identified the things that a class is responsible for knowing, then you have identified the class’s data attributes. Likewise, when you have identified the actions that a class is responsible for doing, you have identified its methods. It is often helpful to ask the questions “In the context of this problem, what must the class know? What must the class do?” The first place to look for the answers is in the description of the problem domain. Many of the things that a class must know and do will be mentioned. Some class responsibilities, however, might not be directly mentioned in the problem domain, so further consideration is often required. Let’s apply this methodology to the classes we previously identified from our problem domain. The Customer Class In the context of our problem domain, what must the Customer class know? The description directly mentions the following items, which are all data attributes of a customer: • the customer’s name • the customer’s address • the customer’s telephone number These are all values that can be represented as strings and stored as data attributes. The Customer class can potentially know many other things. One mistake that can be made at this point is to identify too many things that an object is responsible for knowing. In some applications, a Customer class might know the customer’s email address. This particular problem domain does not mention that the customer’s email address is used for any purpose, so we should not include it as a responsibility. Now, let’s identify the class’s methods. In the context of our problem domain, what must the Customer class do? The only obvious actions are: • initialize an object of the Customer class. • set and return the customer’s name. • set and return the customer’s address. • set and return the customer’s telephone number. From this list we can see that the Customer class will have an _ _init_ _ method, as well as accessors and mutators for the data attributes. Figure 10-12 shows a UML diagram for the Customer class. The Python code for the class is shown in Program 10-20. Program 10-20 (customer.py) 1 # Customer class 2 class Customer: 3 def _ _init_ _(self, name, address, phone): 4 self._ _name = name 5 self._ _address = address 6 self._ _phone = phone 7 8 def set_name(self, name): 9 self._ _name = name 10 11 def set_address(self, address): 12 self._ _address = address 13 14 def set_phone(self, phone): 15 self._ _phone = phone 16 17 def get_name(self): 18 return self._ _name 19 20 def get_address(self): 21 return self._ _address 22 23 def get_phone(self): 24 return self._ _phone The Car Class In the context of our problem domain, what must an object of the Car class know? The following items are all data attributes of a car and are mentioned in the problem domain: • the car’s make • the car’s model • the car’s year Now let’s identify the class’s methods. In the context of our problem domain, what must the Car class do? Once again, the only obvious actions are the standard set of methods that we will find in most classes (an _ _init_ _ method, accessors, and mutators). Specifically, the actions are: • initialize an object of the Car class. • set and get the car’s make. • set and get the car’s model. • set and get the car’s year. Figure 10-13 shows a UML diagram for the Car class at this point. The Python code for the class is shown in Program 10-21. Figure 10-13 UML diagram for the Car class 1 # Car class 2 class Car: 3 def _ _init_ _(self, make, model, year): 4 self._ _make = make 5 self._ _model = model 6 self._ _year = year 7 8 def set_make(self, make): 9 self._ _make = make 10 11 def set_model(self, model): 12 self._ _model = model 13 14 def set_year(self, year): 15 self._ _year = year 16 17 def get_make(self): 18 return self._ _make 19 20 def get_model(self): 21 return self._ _model 22 23 24 def get_year(self): return self._ _year The ServiceQuote Class In the context of our problem domain, what must an object of the ServiceQuote class know? The problem domain mentions the following items: • the estimated parts charges • the estimated labor charges • the sales tax • the total estimated charges The methods that we will need for this class are an _ _init_ _ method and the accessors and mutators for the estimated parts charges and estimated labor charges attributes. In addition, the class will need methods that calculate and return the sales tax and the total estimated charges. Figure 10-14 shows a UML diagram for the ServiceQuote class. Program 10-22 shows an example of the class in Python code. Figure 10-14 UML diagram for the ServiceQuote class Program 10-22 (servicequote.py) 1 # Constant for the sales tax rate 2 TAX_RATE = 0.05 3 4 # ServiceQuote class 5 class ServiceQuote: 6 def _ _init_ _(self, pcharge, lcharge): 7 self._ _parts_charges = pcharge 8 self._ _labor_charges = lcharge 9 10 def set_parts_charges(self, pcharge): 11 self._ _parts_charges = pcharge 12 13 def set_labor_charges(self, lcharge): 14 self._ _labor_charges = lcharge 15 16 def get_parts_charges(self): 17 return self._ _parts_charges 18 19 def get_labor_charges(self): 20 return self._ _labor_charges 21 22 def get_sales_tax(self): 23 return _ _parts_charges * TAX_RATE 24 25 def get_total_charges(self): 26 return _ _parts_charges + _ _labor_charges + \ 27 (_ _parts_charges * TAX_RATE) This Is only the Be Beginning ginning You should look at the process that we have discussed in this section merely as a starting point. It’s important to realize that designing an object-oriented application is an iterative process. It may take you several attempts to identify all of the classes that you will need and determine all of their responsibilities. As the design process unfolds, you will gain a deeper understanding of the problem, and consequently you will see ways to improve the design.