Go Back
  • Polymorphing different Types


    So my friend (though not good enough friend to be my ‘boatfriend’) ran into a programming issue the other day at work. He had two objectswith similar data and no behavior (vb6 style data/procedural programming). Unfortunately,these two objects did NOT inherit from the same base object and they were beingused similarly in an asp.net code behind page but there was no clearabstraction.

     

    If(foo.GetType() == typeof(recurringTransaction))

    {

    Foo1();

    }

    Else

    {

    Foo2();

    }

     

    So basically “foo” could be one of two different types… arecurring transfer or a single transfer. Depending on the type, we’d get adifferent UI behavior.

     

    This is clearly an opportunity for polymorphism, but we didNOT have control of these objects! They were vendor code.

     

    So what do you do in this situation?

     

    Well directly to the point, you would create a new baseclass called “Transfer” and then use composition to encapsulate the dataobjects. Making something like this:

     

    What’s that look like in code?

         class OldSingleTransfer

        {

            //Some data

        }

        class OldRecurringTransfer

        {

            //Some similiar data

        }

        abstract class Transfer

        {

            public abstract void MyUIBehavior();

        }

        class SingleTransfer : Transfer

        {

            OldSingleTransfer instance;

            public override void MyUIBehavior()

            {

                //Specific single transfer code

            }

        }

        class RecurringTransfer : Transfer

        {

            OldRecurringTransfer instance;

            public override void MyUIBehavior()

            {

                //specific recurring transfer code

            }

        }

     Now you can just do foo.MyUIBehavior(); and be done with it.

     I know what you're thinking... GOD that's a LOT of code just to do this one thing. That's not how i would do this.

    Well, yes you're right this is more code initially... however in reality what we had was 40-100 lines of 'type specific' code that was mostly all repeated for both types. We've eliminated all of that duplication and left ourselves with an easier set of operations to maintain and reduced the complexity by removing the conditional logic.

    There were bugs lurking in this code... for example what would happen if you made a third type of transfer? it would have hit the "else" condition... meaning "single transfer". What if it was a scheduled transfer?

    Full story

    Comments (7)

  • Revitalizing a technical career

    Jeremy Miller at Code Better gives some advice to developers who are trying to sharpen their saw.

    It's also good advice for anyone wanting to start a career in software development.

    Similiarly to Jeremy, I wonder if other managers feel the same way about concepts/fundamentals and getting involved with open source projects.

    Of course blogs aren't credible so everything Jeremy says is BS, right?

    I think you're smart enough to decide on your own.

     

    What about his comment that makes the suggestion to move on if you're in a moderate engineering company?

    Are you the rockstar at your shop? Would you rather move on than continue to improve and stay the rockstar?

    Is it true that you're only as good as your weakest link?

    Full story

    Comments (0)