Inheritance « Class « Java Articles

In this simple example, class Apple is related to class Fruit by inheritance, because Apple extends Fruit. In this example, Fruit is the superclass and Apple is the subclass.

How does Java solve the famous diamond problem (caused by multiple inheritance)? That is, you can implement multiple interfaces, that in turn can be implemented by one class. I know that Java has done it; my question is how?

The extends keyword is evil; maybe not at the Charles Manson level, but bad enough that it should be shunned whenever possible. The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements).

We are proud to provide this patterns/strategies repository to the community. Feel free to post any useful design tips you know!

Editor's note: Sometimes, the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. Uncertainty points out an ambiguity in specs, holes in docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will publish one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

In this four-part interview, which will be published in weekly installments, Meyers gives his views on many topics of object-oriented design, including the use of multiple inheritance in light of Java's interface, designing minimal and complete interfaces, public data members and contracts, and the utility of const. In this initial installment, Meyers indicates how his view of multiple inheritance has changed with time, describes the C++ community's take on Java's interface, and points out a schism of focus between the C++ and other prominent development communities.

Create an inheritance hierarchy of Rodent: Mouse, Gerbil, Hamster, etc. In the base class, provide methods that are common to all Rodents, and override these in the derived classes to perform different behaviors depending on the specific type of Rodents. In the main() method of a class named Problem4, create an array of Rodent, fill it with different specific types of Rodents, and call your base-class methods to see what happens.

Another relationship similar to composition is aggregation. Like composition, the aggregation relationship entails a front-end object holding references in instance variables to back-end objects. The difference is intent. In a composition relationship, the front-end objects enlist the help of the back-end objects to fulfill the front-end's semantic contract. In an aggregation relationship, front-end objects merely serve as containers for back-end objects. Front-end objects in an aggregation relationship don't invoke methods on back-ends, they just hold them.

Modeling the relationships between types is a fundamental part of the process of object-oriented design. This chapter shows you how to model relationships using composition and inheritance. It describes many facets of inheritance in Java, including abstract classes and final classes. [bv:need better intro]

Dynamic binding, polymorphism, and change When you establish an inheritance relationship between two classes, you get to take advantage of dynamic binding and polymorphism. Dynamic binding means the JVM will decide at runtime which method implementation to invoke based on the class of the object. Polymorphism means you can use a variable of a superclass type to hold a reference to an object whose class is the superclass or any of its subclasses.

Class extension (full-blown inheritance -- interface and implementation) is like strapping on a backpack in which your instances carry around not only their own instance variables and everything they refer to in a graph of objects, but also those of all their superclasses. If you don't own the superclass, owner can change superclss by adding lots of heavy instance data that gets added to your backpack and you don't have a choice but carry it around everywhere. The owner can also add a method to the superclass interface that you don't like in your subclass, but suddently its a part of your interface whether you like it there or not (or, what's the ultimate problem has, the same signature but incompatible semantics as an existing method in your subclass). If the superclass owner adds lots of heavy instance data to the superclass, that owner basically has added all that weight to your subclass instance's backpack. Your subclass instances have no choice but carry that around everywhere they go. (In a composition relationship you could change the back-end object, delay initilization until needed, share same backend amont multiple front-ends, etc...)

Java Dynamic Management Kit (Java DMK) is a framework for the creation of Java-based management software and legacy SNMP-based systems. It extends Java Management Extensions (JMX), which allows instrumented applications to remotely monitor resources throughout the network.