Dead Duck Typing and High Cohesion

Dietrich Kappe, Friday, December 28, 2007 @ 3:18 pm

I'm sure you're familiar with Duck Typing, in particular as espoused in the Ruby world: "If it walks like a duck and quacks like a duck, I would call it a duck." Nothing is an unmitigated good, but Duck Typing, or designing against interfaces, is generally a good thing. It allows you to abstract away the implementation details, which is a very good thing in the OO world. One thing missing from Ruby, however, is Dead Duck Typing, i.e. when you cook the duck in the oven, you probably don't want it walking and quacking.

Why wouldn't you just have a different class or object, a "Roast" object that you construct when you kill a duck? Well, you might want to do that, sort of like a "Duck Transfer Object," or DTO. But in some cases, creating a separate object, just so it can be used in a different context, adds unnecessary complexity to a system. Take the example of an accessor in Ruby. I may need to give some other Class the information on how long to cook the duck and at what temperature, but do I need to give that to the pillow manufacturer who is only interested in the feathers?

Paddling away from ducks for a moment, think of the typical business and persistence layers in an application. In the persistence layer, the implementation details need to be exposed, in the business layer, they really shouldn't. In Ruby, you can't hide methods in different contexts, so you end up with cluttered interfaces -- monsters instead of ducks -- that rely on good programmer behavior to prevent tight coupling and low cohesion from creeping in (see the GRASP patterns). Instead, we want High Cohesion, i.e. all of the methods of a Class should focus on one or at most a few responsibilities.

Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.

Technorati Tags: ruby, OOAD, GRASP patterns, Duck Typing

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Good post. Programmers will happily point out language a != language b or language c >language a, but when it comes down to OO practices, the ideology is the essentially the same. Ruby is a relatively new language (at least in the mainstream), so expect more and more object orientation in newer releases. PHP finally got some decent OO structure, I expect Ruby to follow.

   Comment by T.J., Friday, December 28, 2007 @ 6:03 pm

Leave a comment