CODEWITHSUNDEEP
c#design-patterns
user3177651
user3177651

Reputation:

What pattern to use in this case (interface implementation)

I have a dataset that can be created by a few ways, one of them is by parsing some text, the other way is from a CSV format, the third way is by importing it from a database.

Currently, this is the interface:

 public interface IMyDataMaker
 {
       public MyDataSet MakeData();
 }

and this is the text parser class:

 public class MyDataSetTextParser : IMyDataMaker
 {
       private readonly string textToParse;
       public MyDataSetTextParser(string text)
       {
            textToParse = text;
       }

       public MyDataSet MakeDate()
       {
            // parse the text and return the dataset
       }
 }

the csv parser is closer to the text parser, this is the database class:

 public class DbMyDataSetMaker : IMyDataMaker
 {
       private readonly SqlConnection connection;
       public DbMyDataSetMaker(SqlConnection sqlConn)
       {
            connection = sqlConn;
       }

       public MyDataSet MakeDate()
       {
            // connect to the db and make the dataset
       }
 }

Is this the correct pattern to use in this case?

Upvotes: 4

Views: 185

Answers (4)

Mukesh Adhvaryu
Mukesh Adhvaryu

Reputation: 646

Yes your approach is correct as already mentioned by our fellow colleagues. However I would like to add something here.

You can use an abstract class to achieve the same.

public abstract class MyDataMaker
{
   public abstract MyDataSet MakeData();
}

Now you may inherit from this abstract class instead of the interface. This should also be a correct design. So the question arises which design to choose in which scenario?

1 If we use interface option, we allow any object from anywhere which implements the interface to come and join the party. You absolutely have no control over that inclusion. It's an universal approach.

2 If we use the abstract option, we will have some degree of control over the object which wants to join the party because we know from which source it originates. That is it must be inheriting from MyDataMaker. Besides you can do some internal, private or even public implementation of some bits and pieces if you wish to do so as abstract does allow this.

So which one is more appropriate when is highly subjective issue and requires thorough clarity on objectives.

And yes, If you plan to allow structure to join the party then abstract option is out because structure is not inheritable so interface is the only option.

Upvotes: 1

Lair Jr
Lair Jr

Reputation: 64

I think this is really good. It's the classic Strategy implementation.

You can now chose the real implementation by dependency injection or creation an method to receive one instance of the interface that you need.

Upvotes: 3

izrik
izrik

Reputation: 952

Just going by your description of your goal, this looks like the right approach. It's not any particular design pattern as much as much good object oriented design. There's an abstract base class/interface that describes how the data sources Can be interacted 38th in a clean way. The consuming class can use any IMyDataMaker given to it, without being concerned 28th the underlying implementation or data source. "Polymorphism" would be the right word for it.

Upvotes: 1

Steve Cooper
Steve Cooper

Reputation: 21480

Yep, that's absolutely the right way to do it. Use constructors to separate out the connection info for each subtype, and end up with a common 'read' method, just as you've done.

Upvotes: 2

Related Questions