lundi 6 septembre 2021

Alternative pattern for setting circular references?

The following types defines segments of a track for a racing game:

enter image description here

Note that there are circular references between TrackFace and TrackSection.

Currently, this is how the circular references are built in Track.Build:

  • create instances of TrackSection and TrackFace
  • use two loops to assign fields and reference to each other

Overall I'm satisfied with this design except that fields are internal.

Please don't suggest that circular references are bad, this is because these properties are computed once and for all, it wouldn't make sense to compute which face belongs to which section and vice-versa, hundreds of times per second.

Alternatively, delegating the work to Track would actually worsen the usability:

  • because getting a face or section now is just a matter of accessing a property
  • performed hit-testing returns faces, fetching the track to simply return a face's section is weird

The only idea I found is to make faces and sections nested in Track...

Notes:

  • the public properties are get-only wrappers around fields to prevent modification
  • serialization of these circular references isn't a problem, it's handled

Question:

How would you go about hiding these internal members, knowing that there are circular references?

Aucun commentaire:

Enregistrer un commentaire