Comments on: Polymorphism Part 2: Refactoring to Polymorphic Behavior

By: John Teague

John Teague — Wed, 08 May 2013 18:43:00 +0000

That’s an interesting opinion. I respect but obviously don’t agree, especially when the code is more difficult than what I can put in a blog post as Artem said. So good luck with that.

By: Artëm Smirnov

Artëm Smirnov — Sun, 05 May 2013 08:19:00 +0000

I guess it depends on the complexity of the original switch statement. Sure in this example it’s better to leave it as it is. However, when it grows up, I’d prefer it scattered among several classes rather than several screens in one file.

By: MBR

MBR — Mon, 25 Mar 2013 20:34:00 +0000

Let me offer a different view — that the switch statement isn’t “code smell”, but the “refactoring” often is. Consider what one accomplishes with this sort of re-factoring:

(1) You still have a switch statement of sorts – however, instead of it being completely under your control, you have now relagated responsibilty to the compiler’s single-inheritence v-table dispatch implementation, which you can not control the behavior of — you are now conflating the semantics of the programming language you are using with the the semantics of your domain.

(2) You have possibly added very serious costs and impedance-mismatches further down the chain, such as changing how serialization and object-mapping function, changing the signature of proxys/stubs to expose as web-services, etc.

(3) You have taken a localized desription of rules that are easily viewed all in one place and scattered them among several classes, and perhaps several source files. I would argue that this certainly does not make the code “easier to test and read”. One set of rules in one place is easier to read, and a single funciton that maps an integer to a string is easier to test than a test requiring several sub-classes of mock objects to be created.

(4) You have taken a step backwards from solving the problem generally – you have taken a “table based” view of your problem, which could easily have been externalized as a workflow in a scripting language or a set of rules in a database, and pushed your logic further into pre-compiled code and a distinct set of classes. Manipulating data is much easier than managing code (meta-programming techniques such as reflection, dynamic code generation, etc.), and offers much more flexibility.

It could be that in a particular case (especially as the consumer of a large web/GUI/etc. framework that uses OOP formalisms) that this type of refactoring is reducing friction overall , but it certainly isn’t a “gimme” that it’s always the right thing to do. (Using the phrase “code smell” is

By: John Teague

John Teague — Thu, 07 Mar 2013 13:30:00 +0000

Yeah, good point. There are a couple of ways to do this. In this case, since they are simple objects and all self contained, you could use the Enumeration pattern I linked to in the article. It gives you a way to the list of possible objects as an array of strings that you could use to bind to a user interface. Then once selected it gives you a way to fetch the object from the string. We use this a lot to list our enumerated classes and rehydrate them.

If however, the objects are more complicated to build and you need more information at initialization time, then use the factory pattern. Inside the factory there will be a switch statement of some kind, but now you’ve isolated that switch to one, *and only one*, location in your application. So if you do need to change it, it only happens in one place.

By: DG

DG — Thu, 07 Mar 2013 09:27:00 +0000

Great little article to remind us of the importance of keeping an eye out for this kind of smell. One thing i always want to see when examples like this are shown is how you setup the Account, how do you assign it its calculator. I always feel like you end up with a switch/if to do that.

By: Aleksandar Dragojević

Aleksandar Dragojević — Wed, 06 Mar 2013 12:56:00 +0000

Nice article, good job, I personally prefer coding to the interface since it makes integrating DI a breeze later on, among other things.

By: The Morning Brew - Chris Alcock » The Morning Brew #1309

The Morning Brew - Chris Alcock » The Morning Brew #1309 — Wed, 06 Mar 2013 09:30:19 +0000

[...] Polymorphism Part 2: Refactoring to Polymorphic Behavior – John Teague continues his series looking at polymorphism, with a look at refactoring procedural code to polymorphic behaviour, converting code which uses switch statements to a more object oriented approach. [...]

By: John Teague

John Teague — Tue, 05 Mar 2013 18:50:00 +0000

Yeah, it’s an important point. I’ll edit it to emphasize this.

Thanks!

By: John Teague

John Teague — Mon, 04 Mar 2013 21:15:00 +0000

yeah, I added it.

By: Marcin

Marcin — Mon, 04 Mar 2013 20:38:00 +0000

You forgot to implement CalculateServiceFee() in PerUserServiceFee class. Right?