Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
8 views10 pages

Chapter 05

The document discusses methods for preserving data integrity through getter and setter methods, which retrieve and change data respectively. It also explains the design principle of decomposition, detailing relationships such as association, aggregation, and composition, along with their representations in UML diagrams and Java code. Additionally, it covers generalization and inheritance, illustrating how shared characteristics can be factored into superclasses and subclasses in object-oriented design.

Uploaded by

resonotech
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views10 pages

Chapter 05

The document discusses methods for preserving data integrity through getter and setter methods, which retrieve and change data respectively. It also explains the design principle of decomposition, detailing relationships such as association, aggregation, and composition, along with their representations in UML diagrams and Java code. Additionally, it covers generalization and inheritance, illustrating how shared characteristics can be factored into superclasses and subclasses in object-oriented design.

Uploaded by

resonotech
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

There are two different kinds of methods typically used to preserve

data integrity. These are:

• Getter methods, which are used to retrieve data. These


methods typically have the format: get<Name of the
attribute>, where the attribute is the value that will be
returned through the method. Getters often retrieve private
data.

• Setter methods, which are used to change data. These


methods typically have the format: set<Name of the
attribute>, where the attribute is what will be changed
through the method. Setters often set a private attribute in a
safe way.

These kinds of methods help ensure that data is accessed in an


approved way.

Decomposition

The design principle of decomposition takes a whole thing and


divides it into different parts. It also does the reverse, and takes
separate parts with different functionalities, and combines them to
form a whole. There are three types of relationships in
decomposition, which define the interaction between the whole and
the parts:

• Association
• aggregation
• composition

All three are useful and versatile for software design. Let us examine
each of these relationships.

Object-Oriented Design | 41
Association

Association indicates a loose relationship between two objects,


which may interact with each other for some time. They are not
dependent on each other—if one object is destroyed, the other can
continue to exist, and there can be any number of each item in the
relationship. One object does not belong to another, and they may
have numbers that are not tied to each other.
An example of an association relationship could be a person and a
hotel. A person might interact with a hotel but not own one. A hotel
may interact with many people.

Association is represented in UML diagrams as below:

Person
0..* 0..* Hotel

The straight line between the two UML objects denote that there is a
relationship between the two UML objects of person and hotel, and
that relationship is an association. The “zero dot dot star” (0…*) on
the right side of the line shows that a Person object is associated
with zero or more Hotel objects, while the “zero dot dot star” on the
left side of the line shows that a Hotel object is associated with zero
or more Person objects.

Association can be represented in Java code as well.

public class Student {


public void play( Sport sport ){
execute.play( sport );
}

}

In this code excerpt, a student is passed a sport object to play, but


the student does not possess the sport. It only interacts with it to
play. The two objects are completely separate, but have a loose
relationship. Any number of sports can be played by a student and
any number of students can play a sport.

Object-Oriented Design | 42
Aggregation

Aggregation is a “has-a” relationship where a whole has parts that


belong to it. Parts may be shared among wholes in this relationship.
Aggregation relationships are typically weak, however. This means
that although parts can belong to wholes, they can also exist
independently. An example of an aggregate relationship is that of
an airliner and its crew. The airliner would not be able to offer
services without the crew. However, the airliner does not cease to
exist if the crew leave. The crew also do not cease to exist if they are
not in the airliner.

Aggregation can be represented in UML class diagrams with the


symbol of an empty diamond as below:

Airliner
0..*
0..* Crew Member

In this diagram, a straight line is used again to symbolize a


relationship between the Airliner object, and the Crew Member
object. “Zero dot dot stars” (0..*) are used to show again that an
object might have a relationship with zero or more of the other
object. In this case, the “zero dot dot star” on the right side of the
line indicates that a Airliner object might have zero or more crew
members. The “zero dot dot star” on the left side of the line
indicates that a Crew Member object can be had by zero or more
Airliner objects. The empty diamond indicates which object is
considered the whole and not the part in the relationship.

Object-Oriented Design | 43
Aggregation can be represented in Java code as well.

public class Airliner {


private ArrayList<CrewMember> crew;

public Airliner() {
crew = new ArrayList<CrewMember>();
}

public void add( CrewMember crewMember ) {



}
}

In the Airliner class, there is a list of crew members. The list of crew
members is initialized to be empty and a public method allows new
crew members to be added. An airliner has a crew. This means that
an airliner can have zero or more crew members.

Object-Oriented Design | 44
Composition

Composition is one of the most dependent of the decomposition


relationships. This relationship is an exclusive containment of parts,
otherwise known as a strong “has-a” relationship. In other words, a
whole cannot exist without its parts, and if the whole is destroyed,
then the parts are destroyed too. In this relationship, you can
typically only access the parts through its whole. Contained parts
are exclusive to the whole. An example of a composition
relationship is between a house and a room. A house is made up of
multiple rooms, but if you remove the house, the room no longer
exists.

Composition can be represented with a filled-in diamond using


UML class diagrams, as below:

House
1..* Room

The lines between the House object and the Room object indicates
a relationship between the two. The filled-in diamond next to the
House object means that the house is the whole in the relationship.
If the diamond is filled-in, it symbolizes that the “has-a” relationship
is strong. The two objects would cease to exist without each other.
The one “dot dot star” indicates that there must be one or more
Room objects for the House object.

Composition can be represented using Java code as well.

public class House {


private Room room;

public House(){
room = new Room();
}
}

Object-Oriented Design | 45
In this example, a Room object is created at the same time that the
House object is, by instantiating the Room class. This Room object
does not need to be created elsewhere, and it does not need to be
passed in when creating the House object. The two parts are tightly
dependent with one not being able to exist without the other.

Generalization

The design principle of generalization takes repeated, common, or


shared characteristics between two or more classes and factors
them out into another class, so that code can be reused, and the
characteristics can be inherited by subclasses.

Generalization and inheritance can be represented UML class


diagrams using a solid-lined arrow as shown below:

Animal

Lion

The solid-lined arrow indicates that two classes are connected by


inheritance. The superclass is at the head of the arrow, while the
subclass is at the tail. It is conventional to have the arrow pointing
upwards. The class diagram is structured so that superclasses are
always on top and subclasses are towards the bottom.

Object-Oriented Design | 46
Inherited superclass’ attributes and behaviours do not need to be
rewritten in the subclass. Instead, the arrow symbolizes that the
subclass will have the superclass’ attributes and methods.
Superclasses are the generalized classes, and the subclasses are the
specialized classes.

It is possible to translate UML class diagrams into code. Let us build


on the example above.

Animal
#numberOfLegs: int
#numberOfTails: int
#name: String
+walk()
+run()
+eat()

Lion

+ Roar()

In this diagram, the Lion class is the subclass and the Animal class is
the superclass. The subclass inherits all the attributes and
behaviours from the superclass. As explained above, it is therefore
unnecessary to put all of the superclass’ attributes and behaviours in
the subclass of the UML class diagram.

You may also notice the use of a # symbol. This symbolizes that the
Animal’s attributes are protected.

Protected attributes in Java can only be accessed by:


• the encapsulated class itself
• all subclasses
• all classes within the same package

Object-Oriented Design | 47
In Java, a package is a way to organize classes into a namespace
that represents those classes.

The UML class diagrams can be translated into code.

public abstract class Animal {


protected int numberOfLegs;
protected int numberOfTails;
protected String name;

public Animal( String petName, int legs, int


tails ) {
this.name = petName;
this.numberOfLegs = legs;
this.numberOfTails = tails;
}

public void walk() { … }


public void run() { … }
public void eat() { … }
}

Since the Animal class is a generalization, it should not be created


as an object on its own. The keyword abstract indicates that the
class cannot be instantiated. In other words, an Animal object
cannot be created.

The Animal class is a superclass, and any class that inherits from the
Animal class will have its attributes and behaviours. Those
subclasses that inherit from the superclass will share the same
attributes and behaviours from the Animal class. Here is the code
for creating a Lion subclass:

public class Lion extends Animal {


public Lion( String name, int legs, int tails
) {
super( name, legs, tails );
}

public void roar() { … }


}

None of the attributes and behaviours inherited from the Animal


class need to be declared. This mirrors the UML class diagram, as

Object-Oriented Design | 48
only specialized attributes and methods are declared in the
superclass and subclass. Remember, the UML class diagram
represents our design. As inherited attributes and behaviours do
not need to be re-stated in the code, they do not need to be re-
stated in the subclass in the diagram.

Inheritance is declared in Java using the keyword extends. Objects


are instantiated from a class by using constructors. With inheritance,
if you want an instance of a subclass, you must give the superclass a
chance to prepare the attributes for the object appropriately.
Classes can have implicit constructors or explicit constructors.

Below is an example of an implicit constructor:

public abstract class Animal {


protected int numberOfLegs;

public void walk() { … }


}

In this implementation, we have not written our own constructor. All


attributes are assigned zero or null when using the default
constructor.

Below is an example of an explicit constructor:

public abstract class Animal {


protected int numberOfLegs;

public Animal( int legs ) {


this.numberOfLegs = legs;
}
}

In this implementation, an explicit constructor will let us instantiate


an animal with as many legs we want. Explicit constructors allow you
to assign values to attributes during instantiation.

public abstract class Animal {


protected int numberOfLegs;

public Animal( int legs ) {


this.numberOfLegs = legs;
}
}

Object-Oriented Design | 49
public class Lion extends Animal {
public Lion( int legs ) {
super( legs );
}
}

A subclass’ constructor must class its superclass’ constructor if the


superclass has an explicit constructor. Explicit constructors of the
superclass must be referenced by the subclass; otherwise, the
superclass attributes would not be appropriately initialized. To
access the superclass’ attributes, methods, and constructors, the
subclass uses the keyword super.

Subclasses can override the methods of its superclass, meaning


that a subclass can provide its own implementation for an inherited
superclass’ method.

public abstract class Animal {


protected int numberOfLegs;

public void walk() {


System.out.println( "Animal is walking"
);
}
}

public class Lion extends Animal {


public void walk() {
System.out.println( "I'd rather nap" );
}
}

In the above example, the Lion class has overridden the Animal
class’s walk method. If asked to walk, the system would tell us that a
Lion object would rather nap.

Types of Inheritance

Java is capable of supporting several different types of inheritance.


The above examples in the lesson are implementation
inheritance.

Object-Oriented Design | 50

You might also like