Parámetros higiénico-sanitarios de la leche de cabra y oveja

With this new model in mind you can rethink the PetStore program devel-oped in Chapter 16. Let’s restate the case:

You are commissioned to develop a program for operating a pet shop which sells dogs, cats, and birds to the public. The owner needs to iden-tify each animal that is available and keep track of its location and sale price. Specifically, the owner also wants to keep track of each dog and cat breed and of the color of each bird. There is a plan to add other pet spe-cies at a future date, so the system should be easily expandable. After an-alyzing the software requirement you propose the following data elements:

1. Each pet is given a name, which is remembered in a string variable.

2. Each pet has a sale price, stored in a variable of type double.

3. A variable of type int keeps track of the location of each pet in the store.

4. There is also species-specific data that must be remembered: the breed of each dog, the breed of each cat, and the color of each bird.

Instead of thinking inheritance, we can consider the problem in sim-pler terms. First we note that there are operations that are the same for dogs, cats, and birds. To avoid duplication and wasted effort we create a class, called Pet, to handle these common operations. Second, the func-tions that are specific to dogs, cats, and birds are implemented in the re-spective classes. Third, the field data for the objects is located in the client classes. The result is that clients have total control over their ob-jects and can expand their functionality as needed. The class diagram of Figure 16-4is modified accordingly, as shown inFigure 17-1.

Figure 17-1 Alternative Class Diagram for the PetStore System

Comparing the inheritance-based class diagram inFigure 16-4with the one inFigure 17-1, you will notice the following differences:

• The arrow that connects the classes Dog, Cat, and Bird with the class Pet does not depict an inheritance relationship. The absence of the semicircle symbol indicates that the classes are not in a “is a kind-of”relationship.

• Since there is no inheritance, the class Pet is no longer an abstract class nor is the method getSpecData() defined in the class Pet.

Pet

getName() getLocation() getPrice()

getSpecData() getSpecData() getSpecData()

name location price dogRace aPet

name location price catRace aPet

name location price birdColor aPet

Dog Cat Bird

• The field variables are now defined in the client classes Dog, Cat, and Bird.

This does not mean that more data is stored by the code, since each object has its own state in either case.

• The client classes Dog, Cat, and Bird contain an object of the host class Pet.

The object is named aPet in all the client classes.

The code must also be changed to reflect the new model. The program PetStore2, listed below, shows the new version. To save space we have implemented only the classes Pet and Dog in the PetStore2 program.

On the Web

The source file for the program PetStore2.java can be found in the Chapter 17 folder atwww.crcpress.com.

//**********************************************************

//**********************************************************

// Program: PetStore2 // Reference: Chapter 17 // Topics:

// 1. Class reuse through object composition

//**********************************************************

// Concrete methods in the base class public void getName(String aName) {

System.out.println ("Pet name: " + aName);

return;

}

public void getLocation(int aLocation) {

System.out.println("Pet location: " + aLocation);

return;

}

public void getPrice(double aPrice) {

System.out.println("Pet price: " + aPrice);

return;

} }

//************************************

// CLASS Dog

//************************************

class Dog {

// Data specific for the Dog class private String dogName;

private int dogLocation;

private double dogPrice;

private String dogBreed;

Pet aPet = new Pet();

// Constructor for the Dog class

public Dog(String name, int loc, double price, String race) {

// Overloaded methods in the Dog class public void getName()

System.out.println("Dog breed :" + this.dogBreed);

return;

//*****************************

public static void main(String[] args) {

// Create two objects of class Dog

Dog dog1 = new Dog("Fido",2, 12.95,"Spaniel");

Dog dog2 = new Dog("Atila",3, 20.75,"Hound");

// Display pet data using host class and client class // methods

dog1.getName(); // Method in host class dog2.getName(); // Method in host class dog2.getLocation();

dog2.getSpecData(); // Method in client class }

}

Aggregation

In the program PetStore2, listed previously, the class Dog is able to access the methods of the class Pet through an object of the class pet called aPet.

The object is created in the following statement:

Pet aPet = new Pet();

In a sense the object aPet is a dummy object, since it serves merely to access methods in the host class. In cases like this we say that the relation-ship between the client and the host class is one of aggregation. In many of the other sample programs listed previously in this book, the driving class creates objects of other classes in order to access their methods. Aggrega-tion is the simplest and most direct way of accessing the public members of another class.

The simplicity and directness of aggregation associations does not make it any less valuable. In many cases aggregation provides an alterna-tive to class inheritance avoiding some of the pitfalls of the more complex model. Aggregation is often depicted in class diagrams by means of an ar-row pointing from the client class to the host, as shown inFigure 17-2.

Figure 17-2 Modeling Aggregation Window

Rectangle width

height aRectangle

area() winArea()