Question 25 of 27: Friend Functions and Modular Programming
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, May 2015. 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 four (4) questions in Part I, any three (3) in Part II, any three (3) in Part III, any two (2) in Part IV, and any four (4) 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 16 questions actually marked (4+3+3+2+4 of 27) each count for 100/16 ≈ 6.25% of the paper. All 27 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 — structural/behavioural pattern catalogue (Adapter, Bridge, Strategy, Observer, Template Method, Composite, 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.
PART I — General Principles (answer any 4 of 7)
Question 25: Friend Functions and Modular Programming (Part V)
friend grants a function or class direct ACCESS to another class's private/protected members, bypassing the encapsulation boundary the class's public interface would otherwise enforce.
Performance benefit. It lets tightly-coupled, performance-critical code (e.g., operator<<, a matrix-multiplication kernel, a custom iterator's implementation) access the internal representation DIRECTLY rather than through possibly-virtual public accessor calls, avoiding call overhead and unnecessary defensive copying in a hot path.
Why it is detrimental to modularity. It breaks encapsulation and information hiding — the central modular-programming principle (also central to Question 19 and Question 23): a friend can read AND WRITE the class's internal representation directly, so the class's actual invariant-preserving interface silently expands to include every friend function/class scattered anywhere in the codebase, not just its declared public methods. Consequences:
The class's internal representation can no longer be changed safely without also auditing and possibly rewriting every friend — defeating the whole point of information hiding, which is the ability to change an implementation without affecting clients. Friends ARE clients that see the implementation, they just aren't marked as such by the public interface.
friend declarations are typically scattered far from the class's own definition, so determining "who can affect this class's invariants" requires a whole-codebase search rather than reading one class's public interface — exactly the traceability cost Question 19 flags for merged responsibilities.
Maintenance risk grows: a maintainer editing the class's private representation must also understand and update every friend, an easy step to miss, unlike a change kept behind a stable public interface, which by definition cannot break well-behaved clients.
Conclusion.friend is a deliberate, narrow escape hatch traded against modularity for a genuine, measured performance need (canonical legitimate uses: operator-overload pairs, tightly-coupled iterator/container pairs) — it should be used sparingly, only where the performance case is real, never as a routine substitute for a proper public interface.
