... | ... | @@ -60,7 +60,7 @@ TODO: insert program code |
|
|
|
|
|
### SharedCar and Arbiter
|
|
|
|
|
|
In the provided code, the arbitration suggested by Jones, Flynn, and Seiger [2, pp. 306] is implemented in the classes ***SharedCar*** and ***Arbiter*** in the "reverse order" compared to the code presented by Jones et al.: The Arbiter goes through the list and for the first ***SharedCar*** whose ***CarCommand*** instance is not null, calls ***CarDriver***'s *perform()* method with the *SharedCar*'s ***CarCommand*** instance and reports the *SharedCar* as the winner. It then breaks the for loop and starts over with the *SharedCar array* from 0, thus always starting from the most competent behaviour layer.
|
|
|
In the provided code, the arbitration suggested by Jones, Flynn, and Seiger [2, pp. 306] is implemented in the classes ***SharedCar*** and ***Arbiter*** in the "reverse order" compared to the code presented by Jones et al.: The Arbiter goes through the list and for the first ***SharedCar*** whose ***CarCommand*** instance is not null, calls ***CarDriver***'s *perform()* method with the *SharedCar*'s ***CarCommand*** instance and reports the *SharedCar* as the winner. It then breaks the for loop and starts over with the *SharedCar array* from 0, thus always starting from the most competent behaviour layer. The reason that this order is "reverse"; is that in the code presented by Jones et al., the arbiter goes through the behaviours in increasing order of competence, overruling the previous setting of the motor input.
|
|
|
|
|
|
Compare this with the arbiter of Fred Martin, [4, page 214-218].
|
|
|
|
... | ... | |