Return to Answer

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows you to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects ahead of time.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, you might consider a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows another option to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects ahead of time.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, it's worth considering a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows you to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, you might consider a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows you to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects ahead of time.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, you might consider a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows you to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

I'm not a fan of assumptions. The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, you might consider a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.

Depending on what methods A and B are doing, you might be able to get away with skipping the suitedForA call and simply attempt each one in order. This assumes by calling methodA when ill-suited, that you'll get an exception. It's a big assumption, but this allows you to avoid duplication.

# if the methods are cheap and easy
def process(object):
    try:
        methodA(object)
    except:
        try:
            methodB(object)
        except:
            methodC(object)

The problem with the above is in cases where no exception is raised. object was suited for B but instead we ran the the incorrect method.

So from a safety standpoint it might be good idea to check for the condition that tells you which method to call. This assumes you have that capability to distinguish between the three objects.

def process(object):
    if suitedForA(object):
        methodA(object)
    elif suitedForB(object):
        methodB(object)
    elif suitedForC(object):
        methodC(object)
    else:
        raise SomeException("We dont know what to do here")

If you own the objects, you might consider a SOLID approach and let them dictate what is the appropriate method to run.

class ObjectA:
    def process(self):
        return methodA(self)

class ObjectB:
    def process(self):
        return methodB(self)

class ObjectC:
    def process(self):
        return methodC(self)


def process(object):
    object.process()

Lastly, sometimes WET code is ok. DRY is a goal, but it isn't the only goal.