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
98-Comp-B11 Advanced Software Design — National Exams, May 2016. 3 hours, closed book exam with one aid sheet 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, agile methods, 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 (Singleton, Proxy, Template Method, Observer, etc.); 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, the open–closed principle; Barbara Liskov's 1987 substitutability paper for Question 11; Rogers, Sharp & Preece, Interaction Design, and Nielsen, Usability Engineering, for Question 21's HMI-specific non-functional requirements; Myers, The Art of Software Testing, for Question 28's boundary value analysis.
PART I — General Principles (answer any 5 of 7)
Question 23: Encapsulation, Information Hiding, and Message Passing (Part V)
Encapsulation is the LANGUAGE-LEVEL construct of bundling an object's data (state) together with the operations that act on that data into a single unit (a class), combined with access control (private/protected/public) that restricts direct external access to the internal data — the class packages state and behaviour as one indivisible unit.
Information hiding is the design PRINCIPLE (Parnas, 1972) that a module's internal implementation details — its data structures and algorithms — should be hidden behind a stable, minimal public interface, so the module's internals can change freely without affecting any client, as long as the interface contract is honoured. This is the same rationale developed for the open–closed principle (Question 22) and for the friend-function discussion (Question 25): a hidden implementation can be changed safely; an exposed one cannot.
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. This is what makes information hiding actually ENFORCEABLE at runtime, not merely a documentation convention: objects can interact ONLY through published messages, never by reaching directly into another object's private data.
How they relate. Information hiding is the WHY (a principle: hide implementation details for independent evolvability); encapsulation is the language-level HOW a class is structured to achieve it (bundling data with behaviour, plus access modifiers that make the data unreachable except through the class's own methods); message passing is the runtime mechanism that then lets objects USE each other despite that hiding, since every interaction is necessarily routed through the receiver's own public interface. Remove message passing and encapsulated objects could not collaborate at all; remove encapsulation's access restriction and message passing would be unenforced, since nothing would stop a caller from bypassing the interface and reading the fields directly.
