0

i'm trying to build a sort of framework for some base process in an app. There is some common behavior where i have to execute some operations but these operations are different depending on some scenarios. I have done something i'm not sure if it's considered a bad practice to make something like this:

public interface IMyDto
{
    string makerIdentifier { get; set; }
}

public class DtoOne:IMyDto
{
    public string makerIdentifier { get; set; }
    //Custom properties for ConcreteOne
}

public class DtoTwo:IMyDto
{
    public string makerIdentifier { get; set; }
    //Custom properties for ConcreteTwo
}

public abstract class AbstractMaker
{
    public abstract void DoSomething(IMyDto myInterface);
}

public class ConcreteMakerOne:AbstractMaker
{
    public override void DoSomething(IMyDto myInterface)
    {
        var concrete = myInterface as DtoOne;
        // If concrete is not null..do stuff with DtoOne properties
    }
}

public class ConcreteMakerTwo : AbstractMaker
{
    public override void DoSomething(IMyDto myInterface)
    {
        var concrete = myInterface as DtoTwo;
        // If concrete is not null..do stuff with DtoTwo properties
    }
}

public class Customer
{
    public void MakeSomething(IMyDto myDto)
    {
        var maker = GetMaker();
        maker.DoSomething(myDto);
    }

    private AbstractMaker GetMaker()
    {
        //Stuff to determine if return ConcreteOne or ConcreteTwo
    }
}

The code im not happy with is the:

var concrete = myInterface as DtoOne;

I would appreciate a lot if someone could give me some advide or tips about a pattern or good oop practice for this scenario.

FredE
  • 71
  • 7
  • 1
    This sounds like a possible use case for the strategy pattern – i.do.stuff Jan 07 '19 at 20:59
  • 1
    What's _"POO"_ mean? – Flydog57 Jan 07 '19 at 21:04
  • 1
    What is a *Maker*? It looks like you are using the *Abstract Factory* pattern but you do not need it since you are not making anything. Like the comment above, the *Strategy* pattern could be enough. However, it would be a lot better if you provide some code without any pattern and then ask which pattern is ideal for that case. I think you're overcomplicating, overengineering this. Patterns are the sexy thing but mostly it just adds complication; though there are times they are needed. – CodingYoshi Jan 07 '19 at 21:08
  • 2
    Did you mean OOP rather than POO? The two have *radically* different meanings! – DavidG Jan 07 '19 at 21:11
  • By the way, that code you are unhappy with is a nasty code smell, I don't know why you would want to cast that at all. Just leave it as the base interface. If you need functionality the only exists in the concrete class then the method should take the concrete class. – DavidG Jan 07 '19 at 21:13
  • Sorry everybody, spanish is my natural language and i wrote OOP as in spanish.. POO.. i fixed it... – FredE Jan 07 '19 at 21:21
  • @CodingYoshi, indeed i'm trying to use the abstrac factory because i have to perform an action, but there are 10 differents way to make it, so i defined 10 different makers .. but i decide which use depending on some logic, i need the concrete type in each maker because, each one needs different parameters to perform its own logic – FredE Jan 07 '19 at 21:30

2 Answers2

0

It's not clear what all of your use cases are, but one option might be generics:

public abstract class AbstractMaker<T> where T:IMyDto
{
    public abstract void DoSomething(T myInterface);
}

public class ConcreteMakerTwo : AbstractMaker<DtoTwo>
{
    public override void DoSomething(DtoTwo myInterface)
    {
        // now you are certain that myInterface is a DtoTwo
    }
}
D Stanley
  • 149,601
  • 11
  • 178
  • 240
0

I am not sure if I understand correctly what are you asking about, but why not just put method DoSomething in IMyDto and implement it differently in DtoOne, DtoTwo, etc.? There would be only one Maker and would always call the same method.

Piotr Wojsa
  • 938
  • 8
  • 22