pros/cons of a ::Base class (rather than acts_as_foo)

Question

Rather than an acts_as_foo syntax**, I'm toying with the idea of extending ActiveSensor::Base < ActiveRecord::Base and then extending this base class with all the errors/validations/class methods/whizbangs.

Proposed: #active_sensor.rb gem

module ActiveSensor
  include ActiveRecord

  autoload :VERSION, 'active_sensor/version'
  autoload :ActiveSensorError, 'active_sensor/base'
  autoload :Base, 'active_sensor/base'
  autoload :Validations, 'active_sensor/validations'
end

Pros: I think it looks cleaner. Architecture and class build-up emulates ActiveRecord I have a lot of subclassing going on... want to check whether a component is hardware using :is_a? method.

Cons: holding an extra inheritance class layer in memory... never used independently not very conventional (only seen 1 other rails plugin do this)

Any advice? Is creating a new ::Base class just dumb? If so, why?

** The acts_as_foo pattern is common for Rails gems. This class method is added to every AR object, which loads and extends class and instance methods when loading the class.

Answer 1

I think you've already answered yourself. Quite simply, if you extend Base then you add the functionality to every Active Record class in your system, whereas if you use acts_as_foo - you can add it only to the models that require it.

Obviously form this, it's better to use acts_as_foo if you only want the functionality for some of your models... but if you want it in every model, then feel free to extend Base.