NivaarExam PrepOfficial exam papers ↗

25-Comp-B11 Advanced Software Design · May 2014

Question 25 of 25: Multiple Inheritance in Java

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

98-Comp-B11 Advanced Software Design — National Exams, May 2014. 3 hours, open book, no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any three (3) questions in Part I, any four (4) in Part II, any three (3) in Part III, any one (1) in Part IV, and any one (1) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 12 questions actually marked (3+4+3+1+1 of 25) each count for 100/12 ≈ 8.3% of the paper. All 25 questions are answered below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — structural/behavioural pattern catalogue (Proxy, Bridge, Strategy, Observer, Template Method, Composite, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics (also underpins the Java/C++ discussion in Part V). Bertrand Meyer's Object-Oriented Software Construction is cited by name where the paper's own vocabulary (design by contract, open–closed principle) originates there; Barbara Liskov's 1987 substitutability paper is likewise cited by name for Question 11.

PART I — General Principles (answer any 3 of 5)

Question 25: Multiple Inheritance in Java (Part V)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Java prohibits multiple inheritance of IMPLEMENTATION (a class extends exactly one superclass) specifically to avoid the diamond problem — ambiguity when two parent classes each supply a conflicting field or method implementation and a common descendant inherits both (C++ solves this with explicit scope resolution and virtual inheritance, at real added complexity, ties to Question 22's broader theme of C++ features traded against simplicity).

Java instead permits multiple inheritance of TYPE: a class may implements any number of interfaces. Historically (pre-Java 8), interfaces could declare only method SIGNATURES, never implementations, so there was no possibility of conflicting inherited implementations at all — only the "is-a-capability" (type) was multiply inherited, never behaviour, which is precisely why Java could allow it safely without a diamond problem.

Since Java 8, interfaces may carry default method implementations, reintroducing a narrow diamond-like case: a class implementing two interfaces that each supply a CONFLICTING default implementation of the same method signature does not compile with either silently chosen — Java forces the implementing class to explicitly override the method (optionally calling InterfaceA.super.method() to select one, or supplying wholly new logic). Java therefore turns the diamond conflict into a mandatory COMPILE-TIME resolution point, rather than resolving it silently or leaving it to be discovered at runtime as unguarded multiple implementation inheritance would.

Practical guidance depends on the characteristics of what is being "inherited." If what's needed is genuinely just a TYPE/capability (a Comparable- or Runnable-style role) with no, or only default, reusable behaviour, implementing multiple interfaces directly is sufficient and idiomatic. If genuine STATE plus substantial behaviour needs to be reused from more than one existing concrete class, Java has no direct expression for "extends A, B" for two classes each carrying instance state — the design is forced into DELEGATION/composition instead (directly, Question 23): hold a private reference to each "would-be parent" and forward the specific operations needed, since only one of them can ever be a genuine superclass.

Back to the paper →