Design Patterns Course Project

The seven-module course project is a small traffic-flow simulation. It provides one stable problem in which object creation, composition, communication, and changing behavior can be examined without requiring a graphical interface.

The first model contains a single intersection with two traffic directions. Vehicles proceed on green and stop on red. Pedestrians cross at the crosswalk only when the pedestrian signal displays Walk. The simulation advances through discrete time steps rather than depending on real elapsed time.

The project covers the simulation model and its control logic. A graphical interface, geographic map, database, and network service are outside the required scope. Keeping those concerns separate allows the same model to be driven by a console program, tests, or a future interface.

Begin with responsibilities rather than pattern names. Candidate domain concepts include:

• Vehicle and Pedestrian: moving entities with a position, direction, and speed;
• Traffic Signal and Pedestrian Signal: expose a current state and determine whether movement is permitted;
• Intersection or Road: defines legal paths and detects conflicting movement;
• Clock: advances simulation time independently of wall clock time;
• Controller: coordinates signals so conflicting directions cannot receive permission simultaneously; and
• Traffic Source: introduces vehicles and pedestrians under a repeatable input policy.

These are candidates, not a final class list. For example, vehicle and pedestrian might share an interface, signal types might share state behavior, and the controller could be divided if it accumulates unrelated responsibilities.

• Conflicting traffic directions must never be released at the same time.
• A pedestrian may enter the crosswalk only when conflicting vehicle movement is stopped.
• The controller must be testable without waiting for real time to pass.
• Adding a new signal timing policy should not require changes to every moving entity.
• A simulation run should be repeatable when supplied with the same input events or random seed.

These invariants provide concrete tests. A pattern is useful only if it helps preserve them while supporting a likely change.

1. Would State make signal transitions clearer than a conditional block?
2. Would Strategy allow timing or traffic-generation policies to change without modifying the controller?
3. Would Observer reduce coupling when displays or metrics need notification, or would direct method calls remain simpler?
4. Would Mediator centralize essential coordination, or create an oversized controller that knows too much?
5. Would Factory Method clarify creation of vehicle types, or merely wrap constructors that are already sufficient?

Do not answer all five by automatically adding all five patterns. Each module should leave the design no more complex than its requirements justify.

1. Identify domain objects and assign one primary responsibility to each.
2. Write a minimal simulation that advances a clock and changes signals.
3. Add executable checks for the safety invariants.
4. Introduce one pattern in response to a specific change scenario.
5. Compare the revised design with the baseline and document the trade-off.
6. Repeat only when another requirement creates new design pressure.

Your first task is to propose the primary objects and classes for this system. Include a brief responsibility for each candidate and identify at least one uncertain boundary that you expect to revisit.

Begin the Course Project Exercise