Skip to content Skip to navigation Skip to collection information

OpenStax-CNX

You are here: Home » Content » Principles of Object-Oriented Programming » Object Relationships

Navigation

Lenses

What is a lens?

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

This content is ...

Affiliated with (What does "Affiliated with" mean?)

This content is either by members of the organizations listed or about topics related to the organizations listed. Click each link to see a list of all content affiliated with the organization.
  • OrangeGrove display tagshide tags

    This collection is included inLens: Florida Orange Grove Textbooks
    By: Florida Orange Grove

    Click the "OrangeGrove" link to see all content affiliated with them.

    Click the tag icon tag icon to display tags associated with this content.

  • Rice Digital Scholarship

    This collection is included in aLens by: Digital Scholarship at Rice University

    Click the "Rice Digital Scholarship" link to see all content affiliated with them.

  • Bookshare

    This collection is included inLens: Bookshare's Lens
    By: Bookshare - A Benetech Initiative

    Comments:

    "Accessible versions of this collection are available at Bookshare. DAISY and BRF provided."

    Click the "Bookshare" link to see all content affiliated with them.

Also in these lenses

  • Busbee's Compter Science display tagshide tags

    This collection is included inLens: Busbee's Computer Science Lens
    By: Kenneth Leroy Busbee

    Comments:

    "Texas Common Course Numbering: COSC1337 or COSC1437"

    Click the "Busbee's Compter Science" link to see all content selected in this lens.

    Click the tag icon tag icon to display tags associated with this content.

  • eScience, eResearch and Computational Problem Solving

    This collection is included inLens: eScience, eResearch and Computational Problem Solving
    By: Jan E. Odegard

    Click the "eScience, eResearch and Computational Problem Solving" link to see all content selected in this lens.

Recently Viewed

This feature requires Javascript to be enabled.

Tags

(What is a tag?)

These tags come from the endorsement, affiliation, and other lenses that include this content.
 

Object Relationships

Module by: Stephen Wong, Dung Nguyen. E-mail the authors

Summary: Relationships between objects can be classified as either "is-a" (inheritance) or "has-a" (composition). These two relationships enable the OO software designer to create abstract models of the desired system.

An object-oriented system can be characterized as a system of cooperating objects. Some objects interact only with certain other objects or perhaps only with a certain set of objects. Sometimes objects are treated as equivalent even though there may be specific differences between them, for instance a situation may call for a "fruit" whereupon an "apple" will do just as well as an "orange". That is, apples and oranges are treated as abstractly equivalent. Conversely, the system designer may want to express the commonality between apples and oranges. An OO system has two distinct mechanisms to express these relationship notions: "is-a" which is technically referred to as "inheritance" and "has-a" which is technically referred to as "composition".

"Is-a" or "Inheritance"

"Is-a" or "inheritance" (sometimes also called "generalization") relationships capture a hierarchal relationship between classes of objects. For instance, a "fruit" is a generalization of "apple", "orange", "mango" and many others. We say that fruit is an abstraction of apple, orange, etc. Conversely, we can say that since apples are fruit (i.e. an apple "is-a" fruit), that they inherit all the properties common to all fruit, such as being a fleshy container for the seed of a plant.

Figure 1: The above diagram shows the "is-a" relationship between Apple, Orange and Mango subclasses and the more abstract Fruit superclass.
UML Class Diagram Showing Inheritance
UML Class Diagram Showing Inheritance (isa.png)

UML Syntax:

Classes are represented by boxes with the class name separated at the top by a horizontal line.

UML Syntax:

Inheritance ("is-a") lines are represented by solid lines with solid arrowheads. The arrow points from the subclass to the superclass (think "a subclass object is-a superclass object")

In Java, inheritance relationships are declared using the extends keyword when declaring a class. A subclass "extends" a superclass, which means that the subclass is a concrete example of the more abstract superclass. For instance, the class Apple would extend the class Fruit.


public class Apple extends Fruit {
	...
}
In Java, a subclass is allowed to extend only a single superclass (no "multiple inheritance"). This restricts the interpretation of a hierarchal taxomony. A subclass is an embodiment of its superclass. It is useful to think of the subclass as not inheriting its superclass's behaviors but rather possessing these behaviors simply because it is the superclass (this is polymorphism). Extend really models what an object intrinsically is--its true "being" as it were. This is particularly useful when the superclass has particular concrete behaviors that all the subclasses should exhibit.

However, "is-a" can really be more of an "acts-like-a" relationship. This stems from the perspective that all objects are defined soley by their behaviors. We can never truly know what an object truly is, only how it acts. If two objects behave identically (at some abstract level) then we say that they are abstractly equivalent. What we need is a way to express the pure behavioral aspects of an object. Java has a the keyword implements which is used to show generalization of a pure behavioral abstraction called an interface. An interface has a similar syntax to a class, but only specifies behaviors in terms of the "signatures" (the input and output types) of the methods. For example we could have


public interface ISteerable {
	public abstract void turnLeft();
	public abstract void turnRight();
}

public class Truck implements ISteerable {
	public void turnLeft() {
		// turn the tires to the left
	}
	public void turnRight() {
		// turn the tires to the right
	}
}

public class Boat implements ISteerable {
	public void turnLeft() {
		// turn the rudder to the left
	}
	public void turnRight() {
		// turn the rudder to the right
	}
}

Java keywords public, abstract and void:

A public class, method or field can be seen and used by anyone. Contrasts with private (seen and used only by that class) and package (seen and used only by classes in the same package). We'll talk more about these later. An abstract class or method is a purely abstract definition in that it specifies the existence of a behavior without specifying exactly what that behavior is. A void return type declares a non-existent return value, that is, no return value at all.
Above, Trucks and Boats are not taxonomically related, but yet they both embody the behaviors of steerability, such as the ability to turn left or right. A person can pilot either a boat or a truck based soley on the fact that they both support turning left or right and not based on what sort of entity they are fundamentally. Note that as per the above definition, a class can implement multiple interfaces at the same time.

Figure 2: The above diagram shows the "acts-like-a" relationships between ISteerable, Boat, and Truck classes
UML Class Diagram Showing Implementation
UML Class Diagram Showing Implementation (actslike.png)

UML Syntax:

Implementation ("acts-like-a") lines are represented by dotted lines with solid arrowheads. The arrow points from the subclass to the interface (think "a subclass object acts-like-a interface")

"Has-a" or "Composition"

"Has-a" or "composition" (sometimes referred to as an "associative") relationships capture the notion that one object has a distinct and persistant communication relationship with another object. for instance, we can say a car "has-a" motor. The car and the motor are not related in a hierarchal manner, but instead we need to be able to express that this pair of objects has a particular working relationship. The car gives gas to the motor and the the motor will propel the car along. Compositional relationships can be one-way, where one object can, in a persistant manner, talk to (i.e. call methods of) a second object but the second object cannot, in a persistent manner, talk back to the first object. Compositional relationships can also be two-way, where both objects can talk to each other in a persistent manner.

Figure 3: The above diagram shows the "has-a" relationships between the Car, Motor and Wheel classes
UML Class Diagram Showing Composition
UML Class Diagram Showing Composition (hasa.png)

UML Syntax:

Composition ("has-a") lines are represented by solid lines with open arrowheads. The arrow points from the owner ("composite") to the ownee ("composee"). Think "a composite has a composee". The number at the arrowhead tells how many composees there are, e.g. 1, 2, etc. "*" means an limited number, so "0...* means zero or more and "1..*" means at least one.

The emphasis made above with regards to persistent communication is deliberate and important. It is indeed possible for an object to communicate with another object in a non-persistent manner. Such non-persistent communication is generally not thought of as a compositional relationship, but rather as a dependency relationship where the action of one object depends on that of another. An object can tell a second object that it (the second object) needs to talk to a specific, perhaps third object. The second object does not know with whom it will be communicating until the first object tells it. The second object may not "remember" the object it is supposed to communicate with for any length of time after the communication was accomplished and the second object merely waits for the first object to tell it with whom to communicate next. This non-persistent communication is normally established by simply passing the third target object as an input parameter to the method call made on the second object by the first. Note that the third object could actually be the first object, creating a non-persistent two-way communication from an initially one-way communication.

Collection Navigation

Content actions

Download:

Collection as:

PDF | More downloads ...

Module as:

PDF | More downloads ...

Add:

Collection to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks

Module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks