Question 22 of 25: 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 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)
PART V — C++/Java and Modular Programming (answer any 1 of 4)
Question 22: 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): 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.
