Solution

ID: past-exam-of-the-year-1-of-the-computer-science-course-of-the-university-of-oxford/2016/imperative-programming/8/d/solution

The diagram omits the type of carType and the concrete constructors. Choose String selectors "convertible", "family", and "sports", no-argument concrete car constructors, and writable temperatureScale and driverSide properties on a fresh Car. Under this explicit interface convention the two methods are:
abstract class Manufacturer {
  def build(carType: String): Car
}

class UKManufacturer extends Manufacturer {
  override def build(carType: String): Car = {
    val car: Car = carType match {
      case "convertible" => new Convertible
      case "family"      => new Family
      case "sports"      => new Sports
      case _ => throw new IllegalArgumentException("Unknown car type: " + carType)
    }
    car.temperatureScale = "Celsius"
    car.driverSide = "left"
    car
  }
}

class USManufacturer extends Manufacturer {
  override def build(carType: String): Car = {
    val car: Car = carType match {
      case "convertible" => new Convertible
      case "family"      => new Family
      case "sports"      => new Sports
      case _ => throw new IllegalArgumentException("Unknown car type: " + carType)
    }
    car.temperatureScale = "Fahrenheit"
    car.driverSide = "right"
    car
  }
}
UK products use Celsius and left-side road traffic; US products use Fahrenheit and right-side road traffic. Here driverSide denotes the side of the road, matching the wording of the source. If the field instead means the side occupied by the steering wheel/driver inside the car, its values must be reversed: right for UK, left for US. The diagram does not resolve that naming ambiguity. With constructor-only immutable properties, pass these same settings to the concrete constructors instead of assigning setters; that is a different interface convention, not a different national policy.
Each branch allocates a fresh concrete Car; it does not reuse mutable cars across orders. Invalid selectors fail explicitly rather than returning null. The base price and description come from the chosen concrete product. Options are applied afterward by wrapping the returned car; build(carType) has no option-list parameter and therefore cannot infer which options a customer wants.

New to topics? Read the docs here!