2

Lets say we have an abstract class called BaseSwitch, inherited by concrete implementations Switch A and Switch B, Each Switch representing a real-life switch (A telephony tool which among its responsibilities is writing CDR; all data records of calls hitting the switch).

Each Switch in real life writes CDR in a different format and to different sources, say some switch writes to a text file another writes to a MySQL database.

The Switches as entities and CDR details are defined by the system's end user

My goal is writing Importer classes responsible for importing CDR based on the source of the data determined by the switch entity into my system, but hiding the Importer from the switch classes.

The layer responsible for importing the CDR will loop upon switches, and instatiate an 'Importer' object, based on the CDR format defined in each switch.

Can anyone suggest an approach to use ?

EDIT : More clarification Below :

public class SwitchBase { public abstract string CDRFormat { get; } }

public class SwitchA:SwitchBase
{
    public override string abc
    {
        get { return "Text"; }
    }


}

public class SwitchB : SwitchBase
{
    public override string CDRFormat
    {
        get { return "MySQLDatabase"; }
    }
}


public class CDR
{ }

public class MySQLImporter
{
    ICollection<CDR> GetCDR()
    {
        //DoSomething
    }
}

public class TextImporter
{
    ICollection<CDR> GetCDR()
    {
        //DoSomething
    }
}

migrated from stackoverflow.com Jan 30 '14 at 19:01

This question came from our site for professional and enthusiast programmers.

  • DI when you know at compile time what specific classes you want. Factory if you won't know until run-time. – psr Jan 30 '14 at 21:33
4

The Factory Pattern allows objects having different types but conforming to the same interface to be created, the specific type which is created being based on some condition. Seems particularly appropriate here.

So create some static methods with different overloads that each accept a different parameter signature and return the appropriate object (polymorphism), or create a single static method and put a switch statement in it that switches over a method parameter and returns the appropriate object.

public static class MyCDRFactory
{
    public static ICDRInterface Create(CDRFormat format)
    {
        switch (format)
            case CDRFormat.Alpha: return new CDRAlpha();

            case CDRFormat.Beta: return new CDRBeta();

        // ..etc
    }
}

ICDRInterface implementations:

public Class CDRAlpha: ICDRInterface
{
    // Implementation for Alpha format goes here
}


public Class CDRBeta: ICDRInterface
{
    // Implementation for Beta Format goes here
}

Usage:

var processor = MyCDRFactory.Create(CDRFormat.Alpha);
  • i'm finding it hard to imagine an implementation for the factory pattern, can you please suggest sample code, just class headers and method signatures using the entities mentioned in the question ? I would really appreciate that. – Siraj Mansour Jan 30 '14 at 18:43
  • See my update... The Factory Pattern is much simpler than all of the UML diagrams would suggest. – Robert Harvey Jan 30 '14 at 18:48
  • Note that this ultimately boils down to simple refactoring; you were already using a switch statement, this just pushes that complexity into its own method. – Robert Harvey Jan 30 '14 at 18:58
  • Harvery, i did not get what do you mean by "you were already using a switch statement". – Siraj Mansour Jan 30 '14 at 19:16
  • Never mind. Too many switches. – Robert Harvey Jan 30 '14 at 19:21

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.