NivaarExam PrepOfficial exam papers ↗

25-Comp-B11 Advanced Software Design · December 2018

Question 23 of 28: Encapsulation, Information Hiding, and Message Passing

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 23: Encapsulation, Information Hiding, and Message Passing (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.

Encapsulation is the LANGUAGE-LEVEL construct of bundling an object's data with the operations that act on it into a single unit (a class), combined with access control (private/protected/public) that restricts direct external access to the internal data.

Information hiding is the design PRINCIPLE (Parnas, 1972) that a module's internal implementation details should be hidden behind a stable, minimal public interface, so the module's internals can change freely without affecting any client.

Message passing is the runtime COMMUNICATION MECHANISM between objects: rather than one object directly reading or writing another's internal fields, it sends a message — invokes one of the receiver's public operations — and the receiver alone decides, using its own hidden internal state, how to fulfil that request.

Implementing information hiding IN CLASS DESIGN, via encapsulation. Within a single class, information hiding is achieved by making all fields private and exposing only the operations that must be public — the class's own internal representation (an array vs. a linked structure, say) can then be changed freely as long as the public method signatures and their contracts (Question 10) are preserved, since nothing outside the class ever touched the fields directly.

Implementing information hiding IN CLASS COUPLING DESIGN, via message passing. Between classes, information hiding is achieved by ensuring collaborating classes interact ONLY through method calls (messages) on each other's public interfaces, never by one class reaching into another's internals (Question 25's friend-function discussion is exactly the exception that proves this rule) — this is what keeps two collaborating classes' respective implementations independently changeable, since their coupling is entirely mediated by the stable message interface rather than by shared internal structure.