Polymorphism Without Side Effects - Object-Oriented Clarity

We discussed in the previous episode how polymorphic behavior gives us a form of a common language for objects.  Thus we need to consider the idea of polymorphism without side effects, so we have clear and concise commands.  There is also a consistency required for this to be an approach that is truly useful.

What Is Polymorphism Without Side Effects

As always, we should start with a definition of terms.  In this case, our goal is clarity.  Polymorphism is a way to give a command each object responds to.  That means there should be similar results for each one.  As an example, if I tell several people to "get the mail," I should be able to assume they either check a physical mailbox or maybe an electronic one.  I should not have some people make me lunch or pay the bills as part of that command.

The Danger of Intent

This challenge revolves around intent.  In our mail example, there are logical assumptions that can be made.  These include scope and other restrictions.  When I ask someone to get the mail, it implies a one-time task and not something that will be done forever.  Likewise, it does not generally imply sending mail at the same time (or paying bills).  These unintended consequences can be described as side-effects.  They can be confusing and even damaging.

The Power of Clarity

We will look at several good habits that make object-oriented programming work well.  Clarity and consistency are two of these.  When we use the same command for different work, it becomes confusing and impacts the user experience.  Instead, we should aim for polymorphism without side effects by clearly defining actions and publicly visible properties.  We can do this by adding context (e.g., printToScreen, printToFile) or other descriptive terms (e.g. printAsXML, printAsJSON)