The most desirable characteristics of an interface relate to its ability to serve as a clear, stable, and robust contract between software components.

1. Clear descriptions of assertions and prerequisites (C): An interface is a contract. This contract must be unambiguous, specifying what the consumer must provide (prerequisites) and what the provider guarantees (assertions/post-conditions). This is fundamental to the "Design by Contract" principle.

2. Hard to misuse (G): A well-designed interface guides developers toward correct usage and makes incorrect usage difficult. This improves system robustness by preventing bugs at the integration points.

3. Easy to extend (A): Systems evolve. An interface should be designed to accommodate future changes and extensions (e.g., adding new functionality) without breaking existing consumers, supporting the system's maintainability and longevity.

B. Geared towards the capabilities of the provider: This is an anti-pattern that leads to tight coupling and violates the principle of information hiding, as the interface would expose implementation details.

D. As few parameters as possible: While a good heuristic for simplicity, it is a means to an end (like being hard to misuse) rather than a primary characteristic itself.

E. Scalable to many consumers: Scalability is a quality attribute of the component's implementation and the underlying infrastructure, not a direct characteristic of the interface's definition.

F. Remotely callable: This is a specific implementation choice relevant for distributed systems; it is not a universally desirable characteristic for all interfaces (e.g., those within a monolith).

---

1. ISAQB e.V. (Ed.). (2018). Curriculum iSAQB Certified Professional for Software Architecture - Foundation Level (Version 3.0.1).

Supporting (C): Section 3.2.2

"Specification of interfaces

" states: "An interface specification should be precise and complete and contain

for example

signature

documentation

pre- and post-conditions as well as information about the required quality of service." This directly supports clear descriptions of assertions and prerequisites.

Supporting (A): Section 1.2

"What is Software Architecture? -> Quality Goals

" lists "flexibility/extensibility" and "maintainability" as key quality requirements that architecture

and by extension its interfaces

must address.

Refuting (B): Section 3.2.2

"Information Hiding

" emphasizes that "The implementation of a component is hidden behind its interface." Gearing an interface towards the provider's capabilities directly contradicts this principle.

2. Parnas

D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM

15(12)

1053–1058. https://doi.org/10.1145/361598.361623

Refuting (B): This foundational paper argues that modules (and their interfaces) should be designed to hide "design decisions that are most likely to change." This means interfaces should be abstract and not based on the provider's specific implementation capabilities.

3. Bloch

J. (2018). Effective Java (3rd ed.). Addison-Wesley Professional.

Supporting (G): Chapter 8

"Methods

" Item 52

discusses designing method signatures. A core theme throughout the book is API design

with a central tenet being that "APIs should be easy to use and hard to misuse." This principle is widely accepted in software engineering and is a key characteristic of a high-quality interface.