3
\$\begingroup\$

I am trying to model this:

  • a Map can have multiple child of type Biomes and no parent
  • a Biome can have multiple child of type Landforms and a Map as its parent
  • a Landform can have multiple child of type Tiles and a Biome as its parent
  • a Tile has no child and a Landform as its parent

I want it to be generic so I can easily add new links to the chain (like adding a new kind of section between Biome and Landform for example). Here is the less ugly solution I have for now :

public class RootSection<T, TChild> : Section<T>
    where T : Section<T>
    where TChild : Section<TChild>
{
    public List<TChild> ChildSection { get; } // duplicate
}

public class MiddleSection<T, TChild, TParent> : Section<T>
    where T : Section<T>
    where TChild : Section<TChild>
    where TParent : Section<TParent>
{
    public List<TChild> ChildSection { get; } // duplicate
    public TParent Parent { get; } // duplicate
}

public class BottomSection<T, TParent> : Section<T>
    where T : Section<T>
    where TParent : Section<TParent>
{
    public TParent Parent { get; } // duplicate
}

public class Section<T> 
    where T : Section<T>
{
    List<T> AdjacentSections { get; }
}

public class Map : RootSection<Map, Biome> { } // (T, TChild)
public class Biome : MiddleSection<Biome, Landform, Map> { } // (T, TChild, TParent)
public class Landform : MiddleSection<Landform, Tile, Biome> { } // (T, TChild, TParent)
public class Tile : BottomSection<Tile, Landform> { } // (T, TParent)

As you can see, there is already duplicate code and I can't think of a solution to get rid of this issue. I feel like I am either missing something obvious or over-complexifying the problem. I also feel like this is close to a classic data structure which I ignore the name preventing me from searching for inspiration on the net.

How can I rewrite this code to look cleaner ? Am I right to think it's close to a well known data structure ?

\$\endgroup\$
6
\$\begingroup\$

I want it to be generic so I can easily add new links to the chain (like adding a new kind of section between Biome and Landform for example)

Generics work fine for simple generic data structures (like a List). Your "generic" data structure is actually a very special one which will not be used outside of your model. It is more a try to extract the common parts of your model to a generic structure which may be useful, but based on your question I can not see the value in your case.

In my experience, data stuctures with multiple generic types, which has contraints to other generic types, are hard to understand and make the code more complicated.

In your case, I would just give generics up and write the data structure down as it is:

public class Map 
{
    public List<Biome> Biomes { get; } = new List<Biome>();
    public List<Map> AdjacentMaps { get; } = new List<Map>();
}

public class Biome 
{
    public Map Map {get; }
    public List<Landform> Landforms { get; } = new List<Landform>();
    public List<Biome> AdjacentBiomes { get; } = new List<Biome>();
}

public class Landform
{
    public Biome Biome {get; }
    public List<Tile> Tiles { get; } = new List<Tile>();
    public List<Landform> AdjacentLandforms { get; } = new List<Landform>();
}

public class Tile
{
    public Landform Landform {get; }
    public List<Tile> AdjacentTiles { get; } = new List<Tile>();
}

Much more readable! The properties has more descriptive names and it needs a minute to extend this hierachical data structure with other types.

\$\endgroup\$
  • \$\begingroup\$ Besides readable, it is by far more understandable. QUESTION: Parent / Child idea is transformed to Adjacent. In as much as "A Tile has no child", for example, is this bad? Is the P/C relationship explicitly relevant for other code? If this is all about composition - A Biome is composed of LandTypes, then I think "Parent/Child" concept is actually misleading. \$\endgroup\$ – radarbob Feb 23 at 23:24
  • \$\begingroup\$ If the parent relation is not relevant for other code, it is indeed misleading because it increases the coupling between the objects unnecessarily. If possible I would avoid it, but it dependence on the requirements. \$\endgroup\$ – JanDotNet Feb 24 at 7:10
  • 1
    \$\begingroup\$ Well, it's not the kind of answer I was expecting since you just really told me to not do it instead of how to do it. The code you posted is really close to what I had before trying to refactor. But I understand why this answer and I decided to leave generics alone for now, it is indeed much more readable but less flexible. Thank you JanDotNet and @radarbob for your inputs on my question. :) \$\endgroup\$ – BenH Feb 24 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.