Section 5.5. Introduction to OOAD | Java for ColdFusion Developers

5.5 Introduction to OOAD

Object-oriented analysis and design is the process for modelling a system to be built. The idea is to describe the situation as it exists in real life, and then apply analytical techniques to translate this into a system that describes the program you will write.

OOAD is more art than science. It requires strong analytical skills. There are not always "right" answers, but, as in life, there are often answers that are more right than others. It is subjective , however, and depends not only on who is designing the system, but also on what the purpose is, what other systems exist in support or in tandem, who the users will be, and many other factors.

The purpose of designing your system with OOAD is to determine, before you start coding, what all the parts of your system are precisely and what they need to be able to do. Your program acts as a director, asking the objects you've identified for information, and then sending messages to workers who perform tasks based on that information.

As mentioned earlier, classes are like little object factories. Objects are the work of the program. When you write a program, you define classes that are called on to make objects that fit its definition. Objects have attributes. Attributes are the qualities of the object or class ”the data about it. These attributes could be name , size , publisher, number of pages, and so on. They also have methods ”the things that they can do.

Objects can call on other objects with which they need to interact to get their work done. This is just like in a company where, for instance, the Web developer needs to interact with the designer to integrate the code with the layout, and then a box administrator is required to address it and put the site up.

5.5.1 Object Identification and Testing

There are a number of ways to identify what things should be objects in your system. Perhaps the best way to begin to design a system is to describe what exactly it needs to be able to do. You can then get an easy start by looking at your text and pulling out the nouns and verbs. The nouns represent objects and the verbs represent methods.

Let's look at our WWWBooks case study to see what objects we can find. It seems clear that we need a Customer object. Those are familiar creatures (hopefully!) who generally have a name, billing information, and possibly contact information. A necessary condition for being a customer is that you have purchased something. Because a customer can purchase more than one thing at a time, and on multiple occasions, we need to isolate each set of purchases as an order. An order needs to know who ordered it as well as what products it comprises. So we should probably have a Product object. Products are sold by booksellers, who are employees. Here is where things generally get interesting. Do we need to represent employees in the system at all? Yes. They are a necessary part of the sale, and the managers want to track the best salespeople. That means that an order needs to know not only who the customer was, but who the seller was. Okay. So what is so interesting about the employee object? Well, managers manage employees, but they are employees too. They are different. They can do things, such as view the top booksellers of the month, that regular employees cannot. They do, however, share a significant number of attributes with regular employees , such as a name, an address, an ID number, a hire date, and a salary. The question then becomes how to best represent that in your system. Do you make a Bookseller object and a Manager object? That doesn't seem quite right. Then you've got to replicate all of the data that booksellers and managers share. If later you decide that you want to expand your "middle initial" attribute to allow for employees' complete middle name, you've got to do it in two places. And what about the owner?

Poor design of the database is one of the chief causes of bloated code, slow performance, and maintenance difficulty in Web applications. Similarly, it is very important to choose the right objects when designing your Java programs. There are ways to determine if what you have chosen to represent as an object is going to work well in your system. This is called object testing. Once you have selected good candidates for objects in your system, consider the following:

Does the object exist in the problem domain? When designing the WWWBooks system, we have a Customer object. The customer's favorite color or place of employment are not really relevant to the transactions the program will perform.
Is the object required to answer the questions the program will ask? While the customer might pay with a debit card that is an extension of a bank account, we don't really need to know the customer's bank account number (as any customer would tell us!). The bank account is outside the problem domain. It does not add to the knowledge that we require to answer the questions the program will ask.
Can the object maintain independent existence? How do you know whether an object should be defined independently as its own object, or whether it should merely be a characteristic of another object? For instance, should the manager object exist independently, or should we just define some kind of "isManager" bit? The customer and the order are clearly independent entities, even though they are related . Should the customer's address be a separate object from Customer ? Employees have addresses too. Maybe it is best to create a separate Address object, and anything in the world of the system that has an address (customers, booksellers, buyers , managers, owner) can use this Address object. Then any relevant changes can cascade throughout the system. The answer is not absolutely clear. A customer at a brick-and-mortar bookstore would generally have no need to give an address to the store. However, a customer buying online would. In the case of the online order, the site visitor can enter two addresses: a billing address and a shipping address. A shipping address is just a certain type of address. Does it make sense to define an entirely different object for the shipping address? That seems like a drag to maintain, and it would require so much extra work writing to begin with. That might be okay if there were some big advantage in performance or functionality, but I can't see what that would be. Also, if we think about it a little more, a shipping address is more or less an aspect of the order, is not necessarily related to the customer, and doesn't necessarily repeat. Probably we should just decide to store the bloody shipping address, if there is one, with the Order object, and go to lunch .
Objects have attributes and operations. All objects must have data that they store as attributes, and operations that they perform. If you cannot define both of these for your object candidate, then you've probably got a characteristic of another object, not an object. For instance, just looking at the nouns in our case study, we might think initially that we need an inventory object. However, inventory is kind of one of those deals like the economy. It doesn't really exist. There are only actual products, and at any given time each product has zero or more of itself in the store. That number is the inventory.

Some related questions arise. What about books and products? Eighty percent of the store's total sales are from books. And a book (as something that can be sold) is a product. However, since such an overwhelming number of books are sold as opposed to the other items, we might want to think about making a separate Book object and a separate Product object. After all a book has an ISBN, which other products don't have. And books get classified by their genre, and other products don't have a genre. However, this is where it is important to look at what you are structurally needing to represent. It could be that an ISBN is not necessarily any different from a product number. It could also be that genre is just a fancy way of saying "category." Again, this probably depends on the size of the store, the number of employees, expected growth, and many other factors.

Once you have described your problem domain, use these tests to determine if you've got a list of objects that makes sense. For now, let's decide on the following objects for WWWBooks:

Customer
Employee
Product
Order

We can reexamine these choices as needed. If these are going to be our objects, we need to determine what their attributes are (the data fields) and what their operations are (their methods).

5.5.2 Modeling Object Attributes and Operations

Attributes can be fields such as customerID , but they can also be objects, such as the Customer object. Let's look at the fields and methods we might choose for each of our system objects. We represent an object by writing its fields (properties), one per line, and then its methods, one per line. Methods are indicated by their trailing () . The act of graphically representing an object as a step in planning an application is referred to as object modeling.

The Product object might look like this:

 productID product productName price discount

etc

 getProductID() getPrice() addToInventory() removeFromInventory()

The Customer object might look like this:

 customerID customerName billingAddress getCustomerID() getCustomerName() getBillingAddress() setBillingAddress()

The Employee object might look like this:

 employeeID hireDate salary getEmployeeID() getHireDate() getSalary()

And here is a possible representation of the Order object:

 orderID orderDate customerID employeeID shippingAddress getOrderID() getOrderDate() getStatus() getOrderEmployeeID() getShippingAddress() placeOrder() cancelOrder()

Note

These are just some reasonable possibilities. One possible improvement to this design is to store the ZIP code and other parts of the address in separate fields. There are a lot of good choices for different designs, and there is no need to get bogged down at this stage.

Note that an attribute can be a reference for another object. Instead of referencing, for instance, the employeeID as we do in the Order object, we could have the Employee object itself be an attribute of the Order object. This would give us access to all of the data in the Employee object through the Order object.

Top