0

I'm currently in the class modeling phase of my project.

Real life Scenario: Let's say I have a Project that is composed of Main Components and each Main Component is composed of Sub Components and each of Sub Components use multiple Materials.

I created a class based on the entities:

public class Project
{
    public List<MainComponent> MainComponents {get; set;}
    // other properties..
}

public class MainComponent
{
    public List<SubComponent> SubComponents {get;set;}
    //other properties..
}

public class SubComponents
{
    public List<Material> Materials {get;set;}
    //other properties..
}

public class Material
{
    //properties..
}

However I will be having a hard time accessing a Material because I will have to go through a nested foreach loop

Let's say projectAlpha is an existing Instance of a Project class

foreach(MainComponent mainComponent in projectAlpha.MainComponents)
{
    foreach(SubComponent subComponent in mainComponent)
    {
        foreach(Material material in subComponent.Materials)
        {
            //do something with material here..
        }
    }
}

What are efficient ways of designing a class that are based on entities that are designed like this? (Avoiding nested loops).

  • This is an example of what LINQ is designed for. – rwong Aug 28 '14 at 1:08
1

I don't think you design is bad or needs replacement. What you have is similar to the Component Pattern. Though, you might consider introducing some of the generalizations from the pattern (depending on your actual use case!).

If accessing all materials from a project is a common usage pattern of a project, rather than implementing the nested loops in each and every place, you should make material retrieval an operation on Project, like Project.AllMaterials. This could be implemented using one loop and delegation to MainComponent.AllMaterials, which, in turn, is implemented by one loop and delegation to SubComponent.Materials. The nested loops are then distributed over the classes and no client needs to care about their internal data structures. Most important, you don't need to reimplement these loops ever again!

Hope this helps!

| improve this answer | |
  • I haven't thought of a retrieval method for that. I only not need access to materials but also all Main Components and Sub Components. I think this is the best answer to my question. Thanks – Blues Aug 27 '14 at 7:18
0

You could maintain a hash map keyed by material id.

Each entry could be a linked list of the mainComponent and subComponent using the material and perhaps a reference to the material object itself.

I should add that you should be careful to delete the index entry if you delete the "material" object. Garbage collection will not delete any object that has a valid reference.

| improve this answer | |
  • does this mean i have to remove the property from the class and link them through the hash map? if that was the case there will be no "Direct" relationship. – Blues Aug 27 '14 at 7:14
  • No you carry on with your original scheme -- logically you just add a "secondary index" keyed by material type. – James Anderson Aug 27 '14 at 8:11

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.