John Teague Blog - Latest Comments

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

John Teague — Wed, 08 May 2013 14:43:57 -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.

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

Artëm Smirnov — Sun, 05 May 2013 04:19:11 -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.

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

MBR — Mon, 25 Mar 2013 16:34:25 -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

Re: Polymorphism: Part 1

Mario Pareja — Wed, 13 Mar 2013 10:41:39 -0000

Now that everyone is hopefully done commenting on your "IWhatever" naming style, I'd like to ask a simple question. What were some of those other things you felt you _did_ learn that you wouldn't otherwise be exposed to?

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

John Teague — Thu, 07 Mar 2013 08:30:38 -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.

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

DG — Thu, 07 Mar 2013 04:27:50 -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.

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

Aleksandar Dragojević — Wed, 06 Mar 2013 07:56:33 -0000

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

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

John Teague — Tue, 05 Mar 2013 13:50:36 -0000

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

Thanks!

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

John Teague — Mon, 04 Mar 2013 16:15:12 -0000

yeah, I added it.

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

Marcin — Mon, 04 Mar 2013 15:38:24 -0000

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

Re: Polymorphism Part 2: Refactoring to Polymorphic Behavior

Caleb Jenkins — Sun, 03 Mar 2013 23:14:42 -0000

" I would not introduce a base class until I really needed too"

Just like you demonstrated.. as a general rule, if I ever feel that a base class would add value, I would still code against the Interface, and simply have the base class implement that Interface.

Nice write up, Thanks John!

Re: Polymorphism: Part 1

John Teague — Fri, 01 Mar 2013 10:41:21 -0000

My development style is more composition than inheritance, so it was just easier for me to make the examples like this. the ISendMessages interface could have easily been an abstract class (I'm hoping to get to an example where it has one). Then the inheritance tree would start from a class. To me however, if you look at how I defined polymorphism, where you have different behavior with a consistent keeping a consistent contract, it doesn't matter if you start from a base class or an interface.

The important part is to use the abstraction, not the concrete implementation. Whether the abstraction is an interface or class you get the same benefits.

HTH,
John

Re: Polymorphism: Part 1

Dbr — Fri, 01 Mar 2013 08:09:43 -0000

Typo - I meant to say "What is it about it that makes it polymorphism?"...

Re: Polymorphism: Part 1

Dbr — Fri, 01 Mar 2013 08:07:09 -0000

Hi. Sorry if this is a little basic, but can you just quickly define "polymorphism" as opposed to "inheritance"? I see the benefit of the way you have written your code, I don't need help with that, but I would just call that a good example of inheriting from an interface? What is it about it that makes it inheritance?

Re: Polymorphism: Part 1

Carlos Ribas — Tue, 26 Feb 2013 12:17:12 -0000

NServiceBus is full of self-contradictions with regards to this "new style" interface naming. IHandleMessages simply aliases the traditionally-named IMessageHandler. There's ISpecifyMessageHandlerOrdering and then there's IMessageCreator (not ICreateMessages?).

This strikes me as ridiculous. If programming were a democracy I'd vote for the "let's stop with the cute English-y stuff" party.

Re: Polymorphism: Part 1

Nathan Alden — Tue, 26 Feb 2013 12:11:15 -0000

Your intent is misplaced and contradicts decades of usage patterns. Additionally, it's factually wrong. An interface does nothing. It merely represents that which does something.

Re: Polymorphism: Part 1

Nathan Alden — Tue, 26 Feb 2013 12:07:29 -0000

ISendMessages? No you don't. You're an interface; you represent that which sends messages. IMessageSender is much more accurate. Please, let's all stop trying to make C# (and other similar languages) read like English; it's infantile.

Re: Polymorphism: Part 1

Matthew Roberts — Tue, 26 Feb 2013 01:13:29 -0000

I recently started learning Objective-C and was surprised to see many objects names were verbs.

But at the end of the day, the compiler wont argue with you - only us humans will =]

Re: Polymorphism: Part 1

John Teague — Tue, 26 Feb 2013 00:08:55 -0000

That was a typo on my part, it should have been OrderProcessor to be consistent with the examples

Re: Polymorphism: Part 1

rmarchet — Mon, 25 Feb 2013 22:22:11 -0000

Great article. Thanks!

I'm not trying to be critical here, but I'm having trouble understanding your use of "OrderSender" in your discussion under the gist block w/ orderprocessor and processorder. The term doesn't show up in any of the code (shown).

I know your busy updating as we speak. So, thanks; and thanks for giving back../rm.

Re: Polymorphism: Part 1

Matthew Roberts — Mon, 25 Feb 2013 21:15:44 -0000

John, its an interesting POV. I personally am not used to this way mainly because the .NET community are well attuned to using singular nouns for object naming (following Microsoft best practises of course!).
I recently started learning Objective-C and was surprised to see many objects names were verbs.

But at the end of the day, the compiler wont argue with you - only us humans will =]

Re: Polymorphism: Part 1

John Teague — Mon, 25 Feb 2013 18:41:40 -0000

Oops, sorry about that. It's not like I actually executed this code ;)

Re: Polymorphism: Part 1

John Teague — Mon, 25 Feb 2013 18:41:14 -0000

If synchronization is a concern, you could wrap it in a lock statement. However, I'm trying to keep the examples free of extraneous concerns to illustrate the concept.

Re: Polymorphism: Part 1

John Teague — Mon, 25 Feb 2013 18:26:45 -0000

I am familiar with Udi's Role Specific, especially after I attended histraining course. This is something different.

I named it the way I wanted. It's just a different style of naming interfaces. It is intentional. If you don't like it fine. I'll be happy to continue this conversation on twitter, skype or email, but it's really not important to the concepts I'm tring to get across.

Re: Polymorphism: Part 1

ChadF — Mon, 25 Feb 2013 17:29:12 -0000

message_sender.Carrier = "carrier";Not to mention _if_ the message sender is shared in a multi-threaded environment.. while Send() can be [implemented as] an effectively atomic action, the carrier set and then send call race condition could have issues. While technically synchronization would be the subject of a completely different article, the threaded expectations (or irrelevance of) is a subtle part of the OOP contract, in practice.