Critical Reflectiononuwestore

Critical ReflectiononUweStore

Jo Turner | 95003648 | MSc Software Engineering
UFCEPM-15-M | Object-Orientated Design & Programming

Contents

Design Objectives

ObjectLists; Self-contained pairings of principle objects

Seperation of UI-specific code

Use of inheritance

ManagerSession (subclass of Session)

Basket (subclass of ItemList)

TUIMenu (superclass of many)

Design Objectives

The principle aim of the design was to makemaintenance and future development as simple as possible.

The rationale behind the key decisions is outlined below.

ObjectLists; Self-contained pairings of principle objects

The principle objects (Principle) in UweStore are Items and Users. These are inherently “listable” objects.

Encapsulating lists of Principles in tightly-coupled classes hides the work of traversing the list. For example, TUIStore performs login by simply calling the UserList’s login functionality; it isn’t expected to traverse the list asking each User if its username matches.

This is not to say that a Principle cannot exist outside of an ObjectList; indeed this is a necessary capability for Principles to have.

By being self-contained,modifying the underlying implementation of one of these (be it a few Items in an ArrayList or a look-up against a database table) should not have any knock-on effects outside of the pairings.

The alternative to using ObjectLists would have been to use stock Java Collections (ArrayLists) to list the

Seperation of UI-specific code

Separation of the user interfacemakes itrelatively simple to implement a new interface.

Let’s assume UweStore later want a GUI.To achieve this, the core functionality shouldn’t need modifying; only a new set of “GUI” classes need to be created that implement the GUI (in the same way the “TUI” classes implement the text interface).

The separation does introduce some complexity to the design. This added complexity is the main compromise in the design. I feel it is justified, as it means that the implementation of the core UweStore functionality is clean and clutter free, so making it easier to work with.

The alternative (and, incidentally, the original design) scattered bits of the user interface across various core source files, resulting in messy classes that are trying to do too many different things and making future maintenance and development more difficult.

Because all text-interface classes use the “TUI” prefix, a new maintainer can quickly ascertain where to look for an issue. Furthermore, interface issues can be resolved without the risk of the core functionality being modified.

Use of inheritance

There are three instances of inheritance:

ManagerSession (subclass of Session)

Using inheritance for ManagerSession avoids duplicating the standard user functionality for the manager while ensuring that a non-managercannever use manager-only functionality.

Basket (subclass of ItemList)

A Basket is a more specialised form of an ItemList, with some additional functionality required. Extending ItemList allows Basket to calculate the value of its contents and to trigger the payment process.

TUIMenu (superclass of many)

The TUIMenu baseclass provides the underpinnings to various text interface classes. Conequently, adding a new menu to the system is very quick and easy, only requiring the programmer to consider what the menu should enable the user to do and how to achieve it without the need to write a lot of support code.

1 | Page