Use the iterator pattern when clients need sequential access to a collection's elements without depending on its internal representation. A collection supplies a traversal object with operations such as
hasNext and next; the client uses the same traversal interface whether the collection is an array, linked list, or another data structure.The iterator keeps the traversal state separate from both the collection and client, so several independent traversals can coexist and the representation can change without rewriting traversal logic. It can also support incremental or lazy evaluation of elements. Exhaustion must have defined behavior, and a mutable collection must define how updates during traversal are handled. The pattern does not by itself promise that arbitrary concurrent modifications are safe.
The two patterns are the factory method pattern and the decorator pattern.
Manufacturer.build is the factory operation specialized by the two national manufacturer software classes. Option and its subclasses wrap a Car to add configurable behavior.For the factory method pattern,
Manufacturer is the abstract creator and declares build(carType): Car; UKManufacturer and USManufacturer are concrete creators. Car is the abstract product interface, and Convertible, Family, and Sports are concrete products. Each national creator selects one product software class from carType and configures the national settings. The diagram does not contain distinct families of national product interfaces or several abstract product-creation operations, so abstract factory pattern is not the most precise identification of this single-operation design.For the decorator pattern,
Car is also the component interface. Convertible, Family, and Sports are concrete components; Option is the abstract decorator, both a subtype of Car and associated with a wrapped Car. DieselEngine, AlarmSystem, and AutomaticTransmission are concrete decorators. Each delegates baseline behavior to its wrapped car, augments description, and adds its surcharge to price. National properties should delegate unchanged through decorators.A customer can compose options, for example
new AlarmSystem(new DieselEngine(baseCar)). Every layer remains usable through the Car interface; each layer adds its own description and price contribution. Factory methods choose/configure the base car, and decorators compose optional additions without requiring a subclass for every option combination. If applying each option at most once is required, enforce that as a separate ordering constraint; unrestricted decorator nesting alone permits repeated options.The diagram omits the type of UK products use Celsius and left-side road traffic; US products use Fahrenheit and right-side road traffic. Here
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
}
}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. Articles by others on the same topic
There are currently no matching articles.