Crossing Arbiter Ifc
Who gets the crossing next, and for how long.
Two decisions, not one, and that is the whole reason this is an object. A single shared resource hides the fact that a crossing arbitrates between two populations with opposite needs, and a model that decides only one of them fails in a way that looks like a modelling error rather than a missing rule:
with only "may this walker start?", vehicles starve under any steady pedestrian flow, because there is never an instant with nobody waiting to cross;
with only "should vehicles be held off?", pedestrians never cross at all, because traffic never happens to leave a long enough gap.
So both belong here, to one substitutable object, which is also what makes a discipline something a study can vary rather than something a model hard-codes. The four that ship (PedestrianPriorityArbiter, VehiclePriorityArbiter, AlternatingArbiter, BoundedBatchArbiter) are the four in the design record's table, and they are there to be compared rather than to be defaults.
Because the population count lives on the zone, a discipline may be written against crowding as well as against time: "admit while fewer than k are on the crossing", "stop admitting once a vehicle has waited t", "close the group when the zone reaches its limit". What is too many is a modelling statement and belongs here; the zone only reports the number.
Inheritors
Functions
May a pedestrian step onto the crossing now?
Should the crossing be held shut against vehicles?
When the crossing should ask again even though nothing has happened.
Told that a turn has ended, so a discipline with a memory can advance it.