Factoring out belongs_to into a common module

I'm factoring out the meat of an ActiveRecord class A into a module M, so that I'm able to duplicate certain data pipelines. The original A had AR macro methods such as belongs_to :X. Although I'm able to separate out non-AR things fine into the module and mix it back into A, the module does not know anything about belongs_to or B out of the box. How do I make those available to the module, and then mix it back into the new shallow A, which only includes M now, and B, which is a clone of A with its own underlying AR table? Or should I write something like an acts_as plugin (right?) instead of M? Ret开发者_StackOverflow社区aining belongs_to in A and duplicating it in B works, but defeats the DRY...

---

When to create a module and when to use inheritance? A question came up today that got me thinking about how much Ruby on Rails developers really understand about the tools they use.

The question related to refactoring two models that shared functionality. A common enough requirement and a very sensible thing to want to do but the comments and solutions raised my eyebrows some what. This was the question, somewhat edited and reformatted to make it clearer

I'm factoring out the meat of an ActiveRecord class A into a module M, so that I'm able to duplicate certain data pipelines.

The original A model had ActiveRecord macro methods such as belongs_to :X.

Although I'm able to separate out non-AR things fine into the module and mix it back into A, the module does not know anything about belongs_to or anything about AR model B out of the box.

How do I make those available to the module, and then mix it back into the new shallow A, which only includes M now, and B, which is a clone of A with its own underlying AR table? Or should I write something like an acts_as plugin (right?) instead of M? Retaining belongs_to in A and duplicating it in B works, but defeats the DRY principle

What I didn't understand was why the person asking the question was putting this code into a module instead of into a class that the models could descend from.

In Rails (almost) every class descends from another class right? You see code like

class MyModel < ActiveRecord::Base

all over the place. Fine that ::Base might seem a little mysterious and I can see how that kind of hides what is going on here so lets look at the controller example

All controllers descend from ApplicationController when first generated right? So you get

class MyController < ApplicationController

How many of you put code into the application controller like before filters and current)user methods and end up using that code in your controllers and views? Once you take time to think about it a bit then you can see that if you put code in ApplicationController that is public or protected then all controllers that descend from ApplicationController get that functionality right?

ApplicationController is just a class that descends from ActionController::Base the definition looks like this

class ApplicationController < ActionController::Base

Now that looks so familiar the above usage is so common that I start to think that a lot of Rails developers struggle to see the wood for the trees.

This is all about inheritance.

Rails puts a bunch of methods into the ActionController::Base and ActiveRecord::Base classes (That's all they are, classes inside a module) so you can descend your own classes from these classes thereby inheriting the methods and functionality provided by these base classes.

So why not create an abstract ActiveRecord::Base class to solve the problem. This seemed to me the most totally obvious and natural approach to take.

I came up with this solution

In a_base_class.rb

class ABaseClass < ActiveRecord::Base
  abstract true
  has_many  :whatevers
  belongs_to :whatevers

  def common_methods
    #some code here
  end

end

Then class a

class A < ABaseClass
  # Whatever
end

This could be placed inside a module for namespacing purposes

If you want to put that in a module then descend from WhateverModule::ABaseClass then that's a cool way of name spacing the new base class so that class names don't conflict and that is one of the main purposes of using a module. To name space classes.

Obviously use whatever real class names that make sense to you.

@Rishav Rastogi provided a great answer for using modules and this is what got mne really wondering why thwe solution was not so clear to others and why the question had even been asked in the first place and I started to get the impression that people don't really know what code like this really does

class SomeController < ApplicationController

and

class MyModel < ActiveRecord::Base

When this is stuff that Rails developers use every day?

It's all about inheritance.

Abstract and non abstract classes all inherit from a single class right? The class being inherited from may well inherit from a number of other classes forming a single inheritance chain but it's still single inheritance. each class only descends from one other class.

So what can modules do to help? Modules are somewhat confusingly used for 2 purposes. 1) To name space things as already mentioned 2) To provide a multiple inheritance scenario. Multiple inheritance is a dirty word in the development world. Things can end up in a right mess but modules provide quite a neat solution.

An example of why you would want multiple inheritance

ActiveRecord::Base provides methods like find_by_something and find.all that return an array of ActiveRecord::Base objects (classes are the code objects are actual things)

Knowing this it would make sense to have the Base class inherit from the array class, but if it did that then it wouldn't be able to inherit from any other more appropriate class. The solution is to mix in a module. If the module contains the array class you get all the juice of array functionality such as .each and .empty? plus all the juice of the other classes that ActiveRecord::Base uses.

So when to use a module and when to inheritance?

Use a module for name spacing (classes can live inside a module)

Use a class for inheritance

So use them both together at the same time unless you want multiple inheritance in which case just use modules

---

Basically belongs_to is a class method. so you can always. You can write a acts_as plugin as well

module ActiveRecord
module Acts
  module M
    def self.included(base)
      base.extend M::ClassMethods
    end

    module ClassMethods
      def acts_as_m
        class_eval <<-CLASS_METHODS
          belongs_to :X
       CLASS_METHODS
     end
   end
 end
end

ActiveRecord::Base.send(:include, ActiveRecord::Acts::M)

class A
 acts_as_m
end 

Its generally just about running class_eval