NivaarExam PrepOfficial exam papers ↗

25-Comp-B11 Advanced Software Design · December 2018

Question 27 of 28: Multiple Class Inheritance via Single Inheritance and Interfaces in Java

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

Notes on this paper

17-Comp-B11 Advanced Software Design — National Exams, December 2018. 3 hours, closed book exam with up to 2 aid sheets allowed (written on both sides), no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any five (5) questions in Part I, any three (3) in Part II, any four (4) in Part III, any two (2) in Part IV, and any five (5) 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 19 questions actually marked (5+3+4+2+5 of 28) each count for 100/19 ≈ 5.26% of the paper. All 28 questions are answered below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, design principles, dependability; 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 — creational/structural/behavioural pattern catalogue and the "program to an interface, not an implementation" / "favor object composition over class inheritance" principles; Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/invariants; Barbara Liskov's 1987 substitutability paper for Question 11; Karl Wiegers, Software Requirements (3rd ed.) — the functional/quality/process/implementation/business requirements taxonomy of Question 2; Kruchten, The Rational Unified Process: An Introduction, for Question 1; Myers, The Art of Software Testing, for Questions 6 and 28.

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

Question 27: Multiple Class Inheritance via Single Inheritance and Interfaces 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).

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 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 unless the implementing class explicitly overrides the method (optionally calling InterfaceA.super.method() to select one). Java therefore turns the diamond conflict into a mandatory COMPILE-TIME resolution point.

Practical guidance depends on what is being "inherited." If what's needed is genuinely just a TYPE/capability with no, or only default, reusable behaviour, implementing multiple interfaces directly is sufficient. 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" — the design is forced into DELEGATION/composition instead (Question 26): 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.