C# – How to avoid having nested generic in class

cclass-designinheritance

I'm working on a side project, and I turned on all rules for code analysis in Visual Studio, and I got the warning notice:

Warning CA1006 Consider a design where 'Vote<T>.CalculateWinner(List<Vote<T>>)' doesn't nest generic type 'List<Vote<T>>'

And it really does point out a sore spot in my design. I have an abstract base class Vote<T> that contains a list of the options for running an election on type T.

Here is what I want to exist:

There are three types of objects, PolicyCategory, Policy and Funding. A PolicyCategory contains a list of votes on the policies within it, and a vote on a Policy must also contain a list of votes on a Funding object. The election procedure (happens to be STV) is then run on the votes in the category, and then on the votes on the winning policy. The procedure is the same for both types of votes.

What I have now is PolicyVote : Vote<Policy> and FundingVote : Vote<Funding>, the core election logic is in Vote<T>, and I have methods that cast List<PolicyVote> to List<Vote<Policy>>, and then call Vote<T>.CalculateWinner().

This is clearly pretty horrible as I'm hacking around the lack of contravariance in C#.

How can this be made better?

Best Answer

I would consider using an interface for Vote instead of generics.

That way if you had something like:

interface IVote {
    // your interface requirements
}

And then on your class definitions implement the IVote interface:

class PolicyVote : IVote {
    // class def
}

class FundingVote : IVote { 
    // class def
}

//etc.

You could then avoid casting to Vote<T> and use IVote as a type instead and any class that implements IVote will be recognised by the compiler as type safe :

public static int CalculateWinner(List<IVote> votes) {
    // your calc logic
}

//You can now pass any object that implements `IVote` to the method
//assuming policyVotes and fundingVotes are type List<IVote>
CalculateWinner(policyVotes); // this will work
CalculateWinner(fundingVotes); // so will this

Related Solutions

Class Design – Method for Loading Data from Multiple File Formats

Strategy Pattern

The strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Here's some excellent examples of the strategy pattern

As you can see from the 1st link above, you can detect the file type in the header in your main method, and then feed the correct version of the Strategy into the context and then call the context.

If you really want to you could write a Factory Method to automatically create your context.

http://www.dofactory.com/Patterns/PatternFactory.aspx#_self2

So you could call something like the following

var context = FileFactory.CreateContext(myFile);
context.Parse();

A factory method might be a little overkill for this however, this would be a judgement call on your part. However using the strategy pattern as above gives you the flexibility to add any number of new file types to parse. Additionally the factory will give you the ability to abstract away all of the polymorphism from your logic code.

Edit

Here is what you would end up with using a strategy pattern combined with a Factory Method.

public interface IFileParserStrategy
{
    IList<Person>  Parse(String path);
}


public class FileFormatNo1 : IFileParserStrategy
{    
   private string _path; 
    public FileFormatNo1(String path){
      _path = path;
    }

    public IList<Person> Parse()
    {
        // Actual Logic for handling File Format #1 
        // and returning a IList<Person>   
    }
}

public class FileFormatNo2 : IFileParserStrategy
{     
    private string _path; 
    public FileFormatNo1(String path){
      _path = path;
    }

    public IList<Person> Parse(String path)
    {
        // Actual Logic for handling File Format 2
        // and returning a IList<Person>   
    }
}

public interface IFileParserContext 
{ 
    public IList<Person> Parse();
}

public class FileParserContext : IFileParserContext
{
    private IFileParserStrategy _strategy;

     public FileParserContext(IFileParserStrategy fileParserStrategy)
     {
         _strategy = fileParserStrategy;
     }

     public IList<Person> Parse()
     {
         return _strategy.Parse();
     }
}

public static class FileParserFactory
{
    public static IFileParserContext CreateContext(String path)
    {
           FileParserContext context = null;

           var checkFileFormat = File.ReadAllLines();

            if(checkFileFormat.Contains("FileFormatNo1"))
              context = new FileParserContext(new FileFormatNo1(path));

            if(checkFileFormat.Contains("FileFormatNo2"))
               context = new FileParserContext(new FileFormatNo2(path));

             if(context == null)
                throw new FileFormatException("File is not in a readable state");

             return context;            
    }       
}


public static void Main()
{    
    var filePath = "someFile.txt";
    var context = FileParserFactory.CreateContext(filePath);    
    var personList = context.Parse();
}

Update

You could modify the above strategy to pass around a FileStream if you only wanted to open the file once. You could modify FileParserFactory.CreateContext to accept a FileStream for its parameter, and refactor the strategies to accept the FileStream instead of the filePath.

public static void Main()
{    
    var filePath = "someFile.txt";
    List<Person> personList;

    using(var fileStream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read)) 
    {
        var context = FileParserFactory.CreateContext(fileStream);    
        personList = context.Parse();
    }        
}

REST API Wrapper – Class Design for ‘Lite’ Object Responses

Based on your description, I would use option three. Option two is probably the worst of the bunch since you would be maximizing duplication and minimizing reuse.

Option one is the inheritance model. I don't feel like it's a good fit for the situation. The resulting class hierarchy will introduce complexity but you won't be gaining much in the trade-off. Inheritance can be very useful when you have a number of different objects which all share a common superclass. In this case you really only have one type of object (a car), you just have varying levels of completeness.

With your single car class from option three, there are some good tricks you can use like lazy loading of properties. Basically if your class has been filled with the least amount of data possible then in the getter of the other properties you can trigger a call out to the more detailed API and fill in the rest of the information. Be careful to model this type of behavior around actual usage patterns the object may see, but it can greatly help with ease of use for other programmers who consume your object.

Best Answer

Related Solutions

Class Design – Method for Loading Data from Multiple File Formats

REST API Wrapper – Class Design for ‘Lite’ Object Responses

Related Topic