Discussion on: Template design pattern in Ruby. Any reason not to use a module instead of a superclass?

[Dan Fockler]

We have both cases in our codebase. The trickiest problems I've seen come when you inadvertently want to end up using instance methods from the subclass (or inheritor) in the abstract class. In either case if you do that you end up creating a coupled dependency and ruining your clean architecture. The difference between these styles is essentially how you want to handle polymorphism.

With inheritance it's more explicit and easier to identify an object's behavior in the code, whereas with composition it's more implicit and duck-typing makes your code more flexible. The second style you showed are called concerns in Rails.

Another issue that I've seen with composition is when you start nesting these modules, and including modules in modules in classes. The deeper you go the harder it is to follow what's happening.

[Brian Kephart]

Thanks for the reply! I thought this seemed like a good approach to the pattern, so it's nice to hear someone else has used it effectively.

... end up using instance methods from the subclass (or inheritor) in the abstract class.

I thought abstract classes weren't meant to be instantiated, just to provide behavior to their subclasses. Have I misunderstood?

[Dan Fockler]

You're definitely right, abstract classes are not meant to be instantiated. That does not mean that the methods they implement are clean from pulling in dependencies, and when mixins/modules end up depending on their child classes (same with abstract classes), then you have problems.

module Commentable
  def comment(text)
    # You now depend on methods of the child class
    self.comments << text 
  end
end

class Post
  include Commentable
end