C # / Salesforce: must limit general, cannot limit general

Question

This question is equal to the parts of C # and Salesforce, maybe solutions from both sides are possible. Suggestions are welcome!

I am writing a generic class to read Salesforce data. The signature is as follows:

public abstract class SalesforceReader<SalesforceObjectType, RecordType> where SalesforceObjectType: sObject 

This allows me to use this code later:

 List<RecordType> records = new List<RecordType>(); QueryResult queryResult = service.query(query); foreach (sObject rawRecord in queryResult.records) records.Add(ConvertRecord((SalesforceObjectType)rawRecord)); ... public abstract RecordType ConvertRecord(SalesforceObjectType record); 

The plan is to write an implementation of this class that knows how to parse, for example, a Salesforce Lead object in RecordType , which can be the main object[] , and Dictionary<string, value> or a fully -defined struct, as I choose later.

So far, I am very pleased with my brilliant elegant solution. My Codey award is as good as winning. Then I try to write an implementation. This definition does not fit:

 class LeadReader: SalesforceReader<Lead, object[]> 

Compiler Result:

 The type 'SalesforceExtractor.Salesforce.Lead' cannot be used as type parameter 'SalesforceObjectType' in the generic type or method 'SalesforceUtilities.SalesforceReader<SalesforceObjectType,RecordType>'. There is no implicit reference conversion from 'SalesforceExtractor.Salesforce.Lead' to 'SalesforceUtilities.Salesforce.sObject'. 

Bummer. I must have a where SalesforceObjectType: sObject in the abstract class, so I can use sObjects, but since the conversion is not implicit, it is not enough for the implementation class.

Do I need to kiss my neat little goodbye decision, or is there a way to save that? This is my first Salesforce project, so if I need to take a different approach, please let me know.

For a bad movie / MST 3K buffs there:

Where "must" and "cannot" occur on the chart?

Answer 1

Yeah, I just had to leave for half an hour and look at her again. After 20 years of working with computers, you would think that I would find out that the problem is usually one of the most promising.

Lead inherits from sObject, but the abstract class was in the library, in a different namespace and project from the implementation class, and each of them used Salesforce WSDL. I asked the compiler to drop SalesforceExtractor.Salesforce.Lead into SalesforceUtilities.Salesforce.sObject, which is not valid. I just had to be more explicit in my implementation class:

 class LeadReader: SalesforceReader<SalesforceUtilities.Salesforce.Lead, object[]> 

This compiles and I think I should be fine.

Answer 2

It looks like you need to change the Lead class to inherit sObject. If these classes do not belong to you, you need to change your design.

Answer 3

The SF Lead object inherits from sObject , so this is the job for type variance , a subset of covariance / contravariance. Good luck with your Codey talk.