Factory pattern with a class that can has different class sub types

Question

I have data from multiple organisations (police, fire, office) that need output in different formats.

To achieve this, I defined the following (this is a little simplified):

Transaction class -

1. "Success" indicator - Boolean.
2. "Type of department"- String or Enum.
3. A class which can be of any type - Police, Fire or Office (My question is on this as you will see).
4. A GenerateOutput() method - to handle generation of file formats.

Police class

1. Age - String
2. VehicleNumber - Integer
3. Supervisor - String

Fire class

1. Name - String
2. FireEngineNumber - Integer
3. County - Enum
4. WorkTimings - Enum

Office Class

1. Age - String
2. DeskNumber - Integer
3. Department - String
4. PayScale - Enum
5. IsManagement - Bool

As you can see, the Police, Fire and Office classes dont share anything in common and are primarily intended as data carrying entities. I intend to use a Factory to return an appropriate generic (not a C# generic) Transaction object with the data (Transaction object with Police, Fire or Office data within it) and then pass the returned object to a Strategy pattern which determines the file format (CSV, Excel, or XML; specified in a configuration file) each one needs.

My problem is in the definition of the Transaction object.

1. What type does the class in "3." of the Transaction class need to be? The data for each org differs, there are no common members, I am unable to define a common class for all.

2. Is the overall design appropriate? What other designs should I consider?

Based on Peter's comments below: I think using generics might work, I ran into a problem though. I would like to use a factory to return the object requested, using GetTransactionObject, as below. What should be the return type of GetTransactionObject to accomodate this.

class TransactionFactory {

        Dictionary<string, Type> typeClassLookup;

    public TransactionFactory()
    {
        typeClassLookup = new Dictionary<string, Type>();
        typeClassLookup.Add("Police", typeof(PoliceData));
        typeClassLookup.Add("Fire", typeof(FireData));
    }

    Transaction<????> GetTransactionObject(string org)
    {

        if( typeClassLookup.TryGetValue(org, out typeValue))
        {
            switch (typeValue.ToString())
            {
                case "policeData":
                    transactionObject = new Transaction<PoliceData>() { Data = new PoliceData(), params = null};
                case "FireData":
                    transactionObject = new Transaction<FireData>() {Data = new FireData(), params = null};
            }
        }
        return transactionObject;

Answer 1

If the types really have nothing in common, then you need no explicit base class. System.Object suffices, just as with many other generic types (i.e. any generic type lacking a constraint).

In other words, you could declare as:

class Transaction<T>
{
    public bool Success { get; private set; }
    public T Entity { get; private set; }

    public Transaction(bool success, T entity)
    {
        Success = success;
        Entity = entity;
    }

    public void GenerateOutput() { /* something goes here */ }
}

Personally, I would avoid adding a "department type" member. After all, that's implicit from the type parameter T. But you could add that easily to the above if you want.

If and when you find that the types do have something in common, such that your Transaction<T> type needs to do more than simply hold onto an instance of one of those types (which is about all it can do without a constraint), then you will be able to put that commonality into an interface or base class (depending on the specific need), and specify that in a constraint for the Transaction<T> class.

Note that it's not clear what you mean for the GenerateOutput() to do, or how it should work. But assuming that you want output that is specific for each Entity value, it seems to me that that is your "something in common". I.e., it's not the Transaction<T> class at all that needs to implement that method, but rather each entity type. In that case, you have something like this:

interface IDepartmentEntity
{
    void GenerateOutput();
}

class Office : IDepartmentEntity
{
    public void GenerateOutput() { /* department-specific logic here */ }
}

// etc.

Then you can declare:

class Transaction<T> where T : IDepartmentEntity
{
    public bool Success { get; private set; }
    public T Entity { get; private set; }

    public Transaction(bool success, T entity)
    {
        Success = success;
        Entity = entity;
    }

    public void GenerateOutput() { Entity.GenerateOutput(); }
}

EDIT:

Per Prasant's follow-up edit, with a request for advice on the GetTransactionObject()…

The right way to do this depends on the caller and the context, a detail not provided in the question. IMHO, the best scenario is where the caller is aware of the type. This allows the full power of generics to be used.

For example:

class TransactionFactory
{
    public Transaction<T> GetTransactionObject<T>()
        where T : IDepartmentEntity, new()
    {
        return new Transaction<T>()
        {
            Data = new T(),
            params = null
        }
    }
}

Then you call like this:

Transaction<FireData> transaction = factory.GetTransactionObject<FireData>();

The caller, of course already knowing the type it is creating, then can fill in the appropriate properties of the transaction.Data object.

If that approach is not possible, then you will need for Transaction<T> itself to have a base class, or implement an interface. Note that in my original example, the IDepartmentEntity interface has only one method, and it's the same as the GenerateOutput() method in the Transaction class.

So maybe, that interface is really about generating output instead of being a data entity. Call it, instead of IDepartmentEntity, something like IOutputGenerator.

In that case, you might have something like this:

class Transaction<T> : IOutputGenerator
{
    // all as before
}

class TransactionFactory
{
    public IOutputGenerator GetTransactionObject(string org)
    {
        if( typeClassLookup.TryGetValue(org, out typeValue))
        {
            switch (typeValue.ToString())
            {
                case "policeData":
                    transactionObject = new Transaction<PoliceData>() { Data = new PoliceData(), params = null};
                case "FireData":
                    transactionObject = new Transaction<FireData>() {Data = new FireData(), params = null};
            }
        }
        return transactionObject;
    }
}

This is an inferior solution, as it means the caller can only directly access the IOutputGenerator functionality. Anything else requires doing some type-checking and special-case code, something that really ought to be avoided whenever possible.

Note: if the Transaction type has other members which, like the GenerateOutput() method, are independent of the contained type T here, and which would be useful to callers who don't know T, then a possible variation of the above is to not reuse the interface used for the department-specific data types, but instead declare a base class for Transaction<T>, named of course Transaction, containing all those members not related to T. Then the return value can be Transaction.

Answer 2

1. What type does the class in "3." of the Transaction class need to be?

To decouple your department classes from the various export types, I recommend you make the department classes implement a common interface. Something like this:

public interface Exportable {
    // return a list of attribute names, values, and types to export
    IList<Tuple<String, String, Type>> GetAttributes();
}

For example:

public class Police : Exportable {
    public IList<Tuple<String, String, Type>> GetAttributes() {
        // return list size 3 - attribute info for Age, VehicleNumber, Supervisor
    }
}

2. Is the overall design appropriate? What other designs should I consider?

The Transaction class design doesn't seem well suited for this problem.

Consider an Export class with a method for each export type, each method which receives the attributes returned from the Exportable interface method. Basic outline:

public static class Export {
    public static boolean CSV(IList<Tuple<String, String, Type>> attributes) {
        // export attributes to CSV, return whether succeeded
    }

    public static boolean Excel(IList<Tuple<String, String, Type>> attributes) {
        // export attributes to Excel, return whether succeeded
    }

    // same thing for XML
}