Gemified Plugins Architecture\Design Patterns in Ruby 2.0

Question

In framework-like ruby projects, how is it possible to package a plugins as gems and then use\\unuse them inside the project, Most popular living example is Rails, but I seeking the abstracted concepts\\practices\\design patterns that can aid in building such project architecture.

Rails sourcecode is TOO big to navigate without a map.

Research Log: - In Rails, Railities are assumed to be a good place to start exploring how plugin architecture is implemented.
- In Ruby 1.8, there was a C extension called mixology that provides mix\\unmix constructs. - In Ruby 1.9.*, It is believed that Rails used alias_method_chain - In Ruby 2.0 prepend keyword is meant to be useful in solving such problem (I assume!)

Answer 1

One of the best introductions into topic I have seen so far was a Railscast where Ryan extracts some piece of his app into a gem:

http://railscasts.com/episodes/301-extracting-a-ruby-gem

Generally there are few rules to follow to make Your code easy extractable:

• Extract common logic to modules or even better separate service objects
• Following SOLID principles will make Your units lean and isolated as much as possible
• ALWAYS namespace Your concerns, service objects, libraries etc
• Test those units completely isolated, don't rely on details like database
• (Controversial) Do dependency injections, You won't regret this when testing and simply when designing APIs between Your objects
• Avoid using Rails helpers as much as possible if You intend Your code to be reusable outside a Rails context

I hope these suggestions will put You on Your own Rails :)