25-Comp-B11 Advanced Software Design · December 2014
Question 23 of 26: 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, December 2014. 3 hours, closed 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 four (4) in Part III, any two (2) in Part IV, and any two (2) 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 15 questions actually marked (3+4+4+2+2 of 26) each count for 100/15 ≈ 6.7% of the paper. All 26 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); Brown, Malveau, McCormick & Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis — anti-pattern catalogue (Question 18). 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 2 of 4)
Question 23: 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 20): 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 20 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.
