A question on architecture and inheritance

[theoneandonlyjim]

I've started a project as a way of transitioning from task-based to object-oriented programming. So far, I wish I'd put the effort in sooner. OOP solves a lot of problems I spent frustrating hours considering ways to get around.

Platitudes aside, I want to make sure I'm making the right choices as I learn, so that the right practices are in place beginning early in the process. I favor a hierarchical architecture similar to what's been discussed in other topics on the board, and an observation I've made as I write is that much of the code falls into two categories: abstraction layers and mediators.

There are both general similarities (queues in and out, auto/manual mode, etc.) and functional differences (power supply vs. multimeter vs. stepper motor), which spawned a thought and a series of questions. I'm considering building a class for a parent abstraction layer and/or a class for a parent mediator, then inheriting as needed. What pitfalls or advantages might I have missed? Will I discover as my skills progress that I've imposed a need for work-arounds? Or, if I'm careful to keep the parent classes away from anything application-specific, will it provide a good base to my coding that can be managed by version control?

[theoneandonlyjim]

OK - I think I'm on my way to figuring this out, but I have a more specific question I hope will generate an answer.

If I pursue this course of action, one of the "Choose Implementation" windows looks like the attachment.

It seems like I leave myself open to slowdown as a result of the large dynamic dispatch tree the project would have to navigate through. Am I right in this thought?

If so, to break it into smaller trees seems like it would require duplicates of the more basic methods that each parent class would have, since their class data would be very similar. This would lead to longer dev time and a larger project. Is this right and would that be this a bigger issue than the potential slowdown?

[Edited to include attachment]

Edited August 26, 2012 by theoneandonlyjim

[Aristos Queue]

It seems like I leave myself open to slowdown as a result of the large dynamic dispatch tree the project would have to navigate through. Am I right in this thought?

There is no performance impact from the depth or breadth of a dynamic dispatch hierarchy. The time needed to dispatch to the correct implementation is constant regardless of the number of classes in memory, the number of methods that a given class has or the number of overrides for a particular method.

[Jordan Kuehn]

There is no performance impact from the depth or breadth of a dynamic dispatch hierarchy. The time needed to dispatch to the correct implementation is constant regardless of the number of classes in memory, the number of methods that a given class has or the number of overrides for a particular method.

I see that you are not a fan of the serial comma.

That aside, thank you for the clarification.

[theoneandonlyjim]

There is no performance impact from the depth or breadth of a dynamic dispatch hierarchy. The time needed to dispatch to the correct implementation is constant regardless of the number of classes in memory, the number of methods that a given class has or the number of overrides for a particular method.

Excellent. I'll leave it alone.

Thank you.

Edited August 27, 2012 by theoneandonlyjim