Should you make use of 'accidental polymorphism'?

Question

Sometimes I find myself in situations where just by happenstance two things can be treated the same way. But they aren't truly the same, it's just coincedence.

Let me give an example, imagine we are in something like JavaScript so that types don't get in the way of my example. Suppose we are writing some event handler, you receive an event, find an instance of some class corresponding to that event and then you're going to call a method of that instance.

Maybe you write this as say a switch statement on the code of the event, or something, and specify which method to execute. Let's suppose there's 10 events to handle, and 6 of them have mutually distinct methods to call, and the remaining 4 all have a method with the same name to call.

But the 4 corresponding classes aren't related in anyway, certainly there's nothing that ensures these methods have the same name.

In this case, should you put these 4 cases in a single switch case?

For me I think, no, as then the code 'suggests' something which isn't so, namely that these 4 cases are related.

Answer 1

Your example is a bit too complicated to make your point. You suggest dynamic dispatch, which actually works pretty much like that... if types get in the way and compile-time is a thing, name-mangling helps resolve identification and entity uniqueness.

What you describe as accidental polymorphism is only possible at the symbolic level. In the conceptual level, you can never have "accidental" polymorphism, because it is about the philosophy. Symbolically, John and John and John is not a sentence that makes much sense. But conceptually, 3 Johns can exist in one room at the same time, because John is a symbol for a concept. To make matters worse, john is occasionally also a colloquialism. Furthermore, run, as a symbol, does not describe anything in the absence of context. Conceptually, you can run() a method, or a Human instance can john.run().

Accidental polymorphism at the symbolic level is common, but accidental polymorphism at the conceptual level is, as Christophe aptly puts it, not accidental. A method and a human are two different types and run is never around without taking the entity into account.

To give an answer to the original question, I need to reformulate it, so that it matches your example. You ask whether it is a good idea to exploit the lack of a type system for static analysis to "retrofit" your code into fewer categories. It is not...

For example fast elf means what it means in English, but in German, it means almost eleven. And then, still, is it eleven* kilograms or eleven o' clock? Context is also important. As you see, symbols coincide, but concepts definitely don't. Code is about using symbols to express concepts. Treating coincident symbols as coincident concepts is not a good idea and is, more often than not, going to confuse anyone else reading your code.

*(Then again, elven and eleven are just one letter away....)

Answer 2

The philosophical question of the day: is it really accidental ?

You are telling us as example, that a switch processes events, and that you realise how some of these processing methods have the same name and from there, go for polymorphism.

Some people would wonder why all your event handlers don’t have the same name for their methods, and why you don’t use some adapter when the actions are a little different.

A similar idea behind is the command pattern: where in fact all changes made on some receivers are all encapsulated behind a command.

So may be it’s not polymorphism by accident, but polymorphism discovered by accident ? ;-)

To dig further

I can recommend you Herbert Simon’s book The science of the artificial. Simon’s an amazing guy who started as nobel prize of economy to end his career as a pioneer in AI. In this book he analysed systems, and he found out that biological systems, human organisations, political systems, and IT systems share a lot more in common that one could imagine at first sight. Who knows: maybe once you’ve read it, you’ll reconsider for ever the word "accidental" in relation with similarity or polymorphism?

Answer 3

Ever heard of duck typing?

Forget what these things “are”. Focus on what they can do for you.

If an algorithm needs to call a, b, & c and x, y, & z each have appropriate a, b, & c’s then feel free to use any of them.

The typing system was never meant to force you to build elaborate is-a taxonomies to make this work. It sometimes gets taught that way but it’s not required.

I very much let use, not hierarchy, drive my designs. So call it accidental if you like. I think of it as sensible.

Answer 4

They should be separate. A unit of code should have one and only one reason to change (the single responsibility principle). But if your switch statement is being against two unrelated objects A and B, then in the future the switch statement might need to be changed to handle a new use case for one of those objects but not the other. A change to make the switch statement continue to work for object A could end up breaking the switch statement for object B.

Programmers like to eliminate or avoid "duplicate" code because it is easy to see, and easy to eliminate. But if that code is handling different use cases it isn't really duplicate. By coupling multiple independent parts of the code base to a single function you end up making the whole code base more fragile.

Answer 5

imagine we are in something like JavaScript so that types don't get in the way

*shudder*

OK my javascript reservations aside there is a movement to allow "anything that fits a interface to be that interface" even if the type doesn't inherit that interface in typed languages.

You'll still get a compile error if you try something that doesn't match the interface, but you don't have the need to explicitly declare interfaces when making the class.

The reasoning is that you can avoid tight-ish coupling between classes via simple universally used interfaces, such as IEnumerable and refactoring classes to add more and more interfaces where you want to use limited subsections of their methods.

However, to my mind this is just syntactic sugar. saving you some typing by dynamically adding the inheritance. Its an argument about whether less typing >= || === less clear code.

In "something like javascript" you are obviously risking runtime errors.. well all the time.. you don't really have a way of enforcing the existence of methods on objects at all, so go crazy and have fun.

In a typed language where you are maybe casting to a dynamic type, or using reflection, you are simply shooting yourself in the foot by not adding and using an interface. Why risk the error when for the want of a bit of typing you can avoid it?

Answer 6

I think it depends on the example. I love DRY code, but @ScottJacobsen's answer has already made Dave Thomas's point that it's knowledge, not the code itself, that's supposed to go unduplicated.

imagine we are in something like JavaScript so that types don't get in the way of my example

I take this to mean, "instead of taking a type-A object in my example and doing a switch over A's subclasses, let's assume several types can be passed to the function", and I agree that's a helpful way to simplify how we think about the issue. But languages that let us do that still vary in how it plays out.

Suppose we want to (add two numbers or concatenate two strings). We can handle cases separately then refactor to taste, maybe getting fewer branches. In JS, a+b would work for all cases, concatenating if one variable's a string and the other's a number. Python could use the same syntax except when we mix, and R would need an if/else even if we don't aim to support the mixed case. If we wanted code that failed on a mixed case, that would actually take more work in JS. So, what works for us is an accident concerning how our aims match against a language's design decisions.

In a more complicated example, the objects might be instances of custom classes. Since our code might become wrong as a class evolves, we've used our knowledge of what works to write the code, and there's no risk of it duplicating knowledge even in the case with a maximal number of branches. By contrast, accidental polymorphism obscures knowledge we're lucky worked out the way it did, so it's going further than DRY advises.

Answer 7

Yes, as long you are coding with this style consistently and you are not relying on what they are. But in reality no, let's see why.

Let me make a short example, you get a Updatable interface

public interface Updatable
{
    public void Update();
}

Now, there are many things that could get be updated, a sound system, a physics system, another algorithm. So there is nothing wrong to have the same interface even though those are very different. However things starts to change if you have to make assumptions internally, in example if you have also real life systems, like controlling real pipes in a chemical plant, you may want to avoid to open close valve continuosly when you are around equilibrium points, you will just wear valves more than needed. In that case maybe you want a Update every 2/3 minutes and not every half second. Functionally the interface is the same, but you have to make distinction because of underlying implementation, regular updates (which is an anti-pattern anyway) and real-valve updates. At this point you'd better live with different interfaces

public interface TickingSystem
{
    public void Update();
}

public interface PipeSystem
{
    public void Update();
}

Resist the temptation to do this:

public interface TickingSystem: Updatable
{
}

public interface PipeSystem:Updatable
{
}

Which is conceptually wrong. Having the same methods, should not be an excuse to have the same interface, as long as it could be potentially used in different ways. A interface is a contract, so "this thing should be used in a certain way".

Eventually you may want to adapt a compatible interface to another compatible interface only for very few specific cases. In that case you take something that should be used like a Pipe, but is so technologically advanced that you get benefits using it as a TickingSystem, but you make that very clear in code, you are adapting something to be used as something else, and you are conscious that you should not do that.

public class FastPipeSystem: TickingSystem
{
     public PipeSystem pipeSystem; // makes clear your are just using a interface

     // accept just the specific types of pipes that can have very fast switching
     public FastPipeSystem(MicroPipe yourFastPipe)
     {
          pipeSystem = yourFastPipe;
     }

     public FastPipeSystem(LazyValvePipeEvenIfFastInput yourFastPipe)
     {
          pipeSystem = yourFastPipe;
     }

     public override Update() //a ticker
     {
          pipeSystem.Update(); // that tick a pipe .. (that can be ticked!)
     }
}

If you make a concrete example on your problem experts on stackoverflow will be happy to see if in your code you have one case or the other, but otherwise this is the most we can say.

Sometimes some interfaces are complex enough to allow to use different behaviours depending on some parameters

public interface ConditionallyUpdatableSystem
{
    public int MillisecondsToWait();

    public void Update();
}

In example such interface allows to select different behaviors depending on result of MillisecondsToWait (in example 0 => continuos ticking, 120000 for pipes etc.) But it is generally bad Idea, because it is really creating a fork where you can avoid the conditional jump just by using 2 specialized different types. Usually complex interfaces are for complex behaviors (and then someone lazily decide to use them for simpler behaviors). In example all interfaces of standard data containers are pretty rich, but someone is free to make simpler container and ignoring the richness of the interface, but at that point is ok, becuase the rich interface was the only viable alternative to resolve a problem. But making more complex interfaces for simple problems instead is generally a bad idea.