Question 3 of 11: MVC, Design Abstractions and Information Hiding

Question 3: MVC, Design Abstractions and Information Hiding (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) MVC and Separation of Concerns

MVC decomposes a GUI application into three collaborating parts, each owning exactly one concern. The Model owns the application's data and business logic and knows nothing about how it is displayed. The View owns presentation — rendering the model's current state to the screen — and contains no business logic of its own. The Controller owns the handling of user input, translating a user action into calls on the model and selecting which view should be shown next. Because each responsibility lives in exactly one place, a change confined to one concern — redesigning the on-screen layout, changing the tax-calculation rule, or adding a new input device — only touches the corresponding component, and the other two are unaffected. This is precisely the separation-of-concerns principle in action: rather than one class mixing data, display logic and input handling together, MVC gives each concern its own module with a defined interface to the others, which is also what allows several different views (a desktop view and a web view, say) to be driven by the same underlying model without duplicating business logic.

(b) Function-Oriented vs. Object-Oriented Abstractions

In function-oriented design (typified by C), the primary unit of abstraction is the function (procedure): a named, reusable operation that hides its internal algorithm behind a fixed argument list and return type, so a caller need not know how the function computes its result, only what it computes. A secondary abstraction is the data structure or record (a C struct), which groups related fields together, though the data and the functions that operate on it remain textually and conceptually separate. In object-oriented design (typified by Java or C++), the primary abstraction is the class/object, which bundles data (attributes) and the behaviour that operates on that data (methods) into a single unit — encapsulation. OO design adds two further abstraction mechanisms function-oriented design lacks in the same form: inheritance, which lets a class be defined as a specialisation of a more general class, and interface/abstract-class abstraction, which lets a contract of operations be specified independently of any concrete implementation.

(c) Information Hiding

Information hiding, as formulated by Parnas, is the principle of concealing a module's internal implementation decisions — its data structures, algorithms and any details likely to change — behind a stable public interface, so that other modules interact with it only through that interface and remain unaware of, and unaffected by, what lies behind it. It matters because most software changes over its lifetime, and a module whose internals are hidden can be re-implemented (a different data structure, a faster algorithm) without forcing any change on the modules that use it, so the ripple effect of change is contained. Information hiding directly benefits Maintainability (internal changes stay internal), Reusability (a module can be reused purely through its interface, without a client needing to understand its implementation), and Security (sensitive data or logic behind the hidden boundary cannot be manipulated except through the sanctioned interface).

Practical Application

A payment module that hides which payment gateway it calls behind a single processPayment(amount) interface lets the organisation switch payment providers later by rewriting only the module's internals — exactly the maintainability benefit information hiding is meant to deliver, and precisely the separation MVC applies at the level of an entire GUI application.