Which design pattern do I have

Question

I have two classes, each of them doing same thing but only differences are, that they both use different logic in some function in the code. Let say:

class A
{
    //has same fields, and method
    void GetDataTable()
    {
         //logic here changes up to table of the database and for some fields.
    }
}

class B
{
    //has same fields, and method
    void GetDataTable()
    {
         //logic here changes up to table of the database and for some fields.
    }
}

At the end of the day, I would add another same behaving class and GetDataTable method with different logic. What kind of design pattern or OO technique I have to apply for more quality code.

Answer 1

You're probably looking for the Strategy Pattern.

You define an interface with the method that each "logic" class has to implement. Each "logic" class will implement this interface and performs its logic in the implemented method.

interface IGetDataTable
{
    void GetDataTable();
}

class A : IGetDataTable
{
    public void GetDataTable() { /* Do logic here for class A */ }
}

class B : IGetDataTable
{
    public void GetDataTable() { /* Do logic here for class B */ }
}

You then choose the appropriate class (that implements IGetDataTable) for your needs.

Answer 2

No pattern per se, just inheritance.

I've used an abstract class instead of an interface because you mentioned there are common methods.

public abstract class MyBaseClass
{
    // TODO: Common methods here.

    // Inheriting classes must implement this.
    public abstract void GetDataTable();
}

public class A : MyBaseClass
{
    public void GetDataTable()
    {
        // Specific implementation here.
    }
}

public class B : MyBaseClass
{
    public void GetDataTable()
    {
        // Specific implementation here.
    }
}

If you have something that uses these classes - but only the GetDataTable method then it would be good practice to have an interface. IGetDataTable for example.

If not, there's no need, the abstract class is the interface.

public interface IGetDataTable
{
    void GetDataTable();
}

public abstract class MyBaseClass : IGetDataTable
{
    // TODO: Common methods here.

    // Inheriting classes must implement this.
    public abstract void GetDataTable();
}

public class A : MyBaseClass
{
    public void GetDataTable()
    {
        // Specific implementation here.
    }
}

public class B : MyBaseClass
{
    public void GetDataTable()
    {
        // Specific implementation here.
    }
}

Answer 3

As Styxxy suggest I use strategy pattern like that:

Refactoring code so result are:

-More flexible.
-Can change behavior at runtime
-no code duplication

class Program
{
    static void Main(string[] args)
    {
        Apply a = new Apply(); //I will create if I dont need any logic but be able to get AB's behavior, I will call that class NoApply
        Helper(a);

    }
    static void Helper(AB myobj)
    {
        myobj.CanGetDataTable();
    }
}

abstract class AB
{
    IGetDataTable gtb;

    public virtual void LogicSetter(IGetDataTable dt)
    {
        gtb = dt;
    }

    public void CanGetDataTable()
    {
        this.gtb.GetDataTable();
    }
    public void DoSameThingBothAB()
    {
        Console.WriteLine("do same things");
    }
}

class Apply:AB
{
    public Apply()
    {
        base.LogicSetter(new LogicForA());
    }
}

public interface IGetDataTable
{
    void GetDataTable();
}

public class LogicForA:IGetDataTable
{
    public void GetDataTable()
    {
        Console.WriteLine("logic for A");
    }
}

public class LogicForB:IGetDataTable
{
    public void GetDataTable()
    {
        Console.WriteLine("logic for B");
    }
}

public class LogicforFutured:IGetDataTable
{
    public void GetDataTable()
    {
        Console.WriteLine("logic for object created in 2019");
    }
}

Answer 4

You can use Strategy Pattern, or simply make common abstract ancestor for both of the classes.