Question 9 of 11: Signatures, Visibility and Module Interfaces

Question 9: Signatures, Visibility and Module Interfaces (10 marks)

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.

(a) Full Signature

The full signature of a method or function is everything a caller needs to identify it uniquely and invoke it correctly: its name, its ordered list of parameter types, and its return type (and, in languages that require it, the checked exceptions it may throw). For example, the Java method public double calculateInterest(double principal, double rate, int years) throws InvalidRateException has the signature calculateInterest(double, double, int); a second method also named calculateInterest but taking a different parameter list is a distinct signature under overload resolution, even though the two share a name.

(b) Visibility: Public, Private, Protected

Visibility governs which other parts of a program may access a given method, function or variable of a module. Public members are accessible from any other module or class in the program (and typically from outside the defining package or library), and form the module's intended external interface. Private members are accessible only from within the module or class that defines them, hiding internal implementation detail so no other module can depend on it. Protected members are accessible from within the defining class and from its subclasses, but not from unrelated classes — a middle ground that exposes internals to a class's own inheritance hierarchy for extension while still hiding them from the rest of the program.

(c) Module Interfaces: Function-Oriented vs. Object-Oriented

In a function-oriented system, a module's interface is the set of public function signatures (and any shared data structure declarations) it exposes for other modules to call; for example, a stack module's header might declare push(item), pop() and isEmpty() as its interface, while the array or linked-list implementation behind those three functions is hidden from every caller. In an object-oriented system, a module's (class's) interface is the set of public methods it exposes — and, in languages with an explicit interface construct, a separate named contract (such as a Java interface) listing method signatures with no implementation at all. A List interface declaring add(), get() and remove() lets client code depend only on that contract, while ArrayList and LinkedList supply two entirely different hidden implementations behind the same interface.

Practical Application

Publishing a stable interface — the stack module's three functions, or the List interface — is what lets a library's internal implementation be replaced or optimised in a later release without breaking any code written against it, so long as the signature and visibility contract are preserved.