Choose and design an appropriate user-defined data type for a given problem

Published by Patrick Mutisya · 14 days ago

Cambridge A-Level Computer Science 9618 – 13.1 User‑Defined Data Types

13.1 User‑Defined Data Types

Learning Objective

Choose and design an appropriate user‑defined data type for a given problem.

Why Use User‑Defined Data Types?

  • Encapsulate related data items into a single logical entity.
  • Improve code readability and maintainability.
  • Enable type checking by the compiler/interpreter.
  • Facilitate abstraction – the implementation can change without affecting the rest of the program.

Common Forms in A‑Level Syllabus

  • Records / Structures – a collection of fields of possibly different primitive types.
  • Enumerated Types (enum) – a set of named constant values.
  • Classes (object‑oriented) – combine data (attributes) and behaviour (methods).

Design Process for a User‑Defined Type

Follow these systematic steps:

  1. Analyse the problem and identify the real‑world entities involved.
  2. Determine the attributes each entity must store.
  3. Decide on the most suitable representation (record, enum, class).
  4. Define the type using the language syntax.
  5. Write supporting operations (constructors, accessors, mutators) if required.
  6. Test the type with representative data.

Example Problem

Design a data type to represent a library book in a system that tracks borrowing.

Step‑by‑Step Design

StepActionResult
1Identify entity: BookNeeds to store title, author, ISBN, availability, borrower ID.
2Choose representationRecord (or class) because fields are of different types.
3Define type (pseudo‑code)

type Book is record

title : string

author : string

isbn : string

isAvailable : boolean

borrowerID : integer // 0 if not borrowed

end record

4Write operations

  • borrow(b: Book, id: integer): Book
  • return(b: Book): Book
  • display(b: Book): void

5Test with sample dataCreate a Book instance and simulate borrowing/returning.

Key Points to Remember

  • Each field should have a clear purpose and appropriate primitive type.
  • Prefer records for simple aggregation; use classes when behaviour is required.
  • Enumerated types are ideal for a fixed set of values (e.g., days of the week, traffic‑light states).
  • Consistent naming conventions aid readability.

Suggested Diagram

Suggested diagram: UML class diagram showing the Book record with its fields and associated operations.

Practice Question

Design a user‑defined data type for a student’s exam result that includes the student’s ID, name, a list of marks for three subjects, and a method to calculate the average mark. Outline the design steps and provide a definition in pseudo‑code.

Answer Outline

  1. Identify entity: ExamResult.
  2. Attributes: studentID (integer), name (string), marks (array[3] of integer).
  3. Choose representation: Record (or class).
  4. Define type:

    type ExamResult is record

    studentID : integer

    name : string

    marks : array[1..3] of integer

    end record

  5. Operation to compute average:

    function average(r: ExamResult) : real

    total := 0

    for i from 1 to 3 do

    total := total + r.marks[i]

    end for

    return total / 3

    end function

Summary Checklist

  • Have I identified all relevant attributes?
  • Is the chosen representation (record, enum, class) appropriate?
  • Are field types compatible with the data they will hold?
  • Did I include necessary operations for the type?
  • Have I tested the type with realistic examples?