pluginによるメソッドすげかえの危険性 - 思っているよりもずっとずっと人生は短い。

上に関連するかも。

ActionMailer 日本語化プラグイン（drawnboyさん）
http://d.hatena.ne.jp/drawnboy/20051113/1131822348

pluginでこの手の方法(create!すげかけ)を使うと、例えば他に同様なことを行うpluginがあった場合に問題が起きるのは明らかです。それを回避するためには、 http://wota.jp/ac/?date=20050731#p01 のように別クラスにするべきでしょう。

ていうか、こういうのってOCP(開放・閉鎖原則)に違反しているような気がするんですけど、どうなんでしょうか？

追記：すみません、上の記述はまずいですね。問題が発生するとは限りません。というか、直接発生することは少ないかも。
でも、変更がグローバルなものになる(同一プロセスで同じクラスを使っているものすべての挙動が変更される)という点では、おすすめしたくないのは同じです。驚かせてしまったらごめんなさい。

なお、もともと(?)のActiveHeartにも同様の問題があるのは知っています。が、ActiveRecord::Baseはサブクラスに別の意味が出てくる(SingleTableInheritanceになる)ので、安易にサブクラスを作るとはまりそうな気がします（このあたりはソースを追っかけていないので自信なし）。ので、仕方ないのかなと。

……というのも、元々はActiveRecordのエラーメッセージの日本語化を自分でもやってみていて、その結果同様の方法(human_attribute_nameすげかえ)に行き着いてしまい、気持ち悪さをおぼえながらも仕方ないなと使ってしまったことが頭に残っていたのでした。しかも当時はpluginもなかったためいきなり書き換えてしまっていたし、そもそもhuman_attribute_nameが安定したインターフェースである保証もなかったので互換性もよくわからないし(Rails追っかけならRuby 1.8.3での互換性を壊す原因になったLoggerの定数のすげかえを思い出してください)、と思ってそのままお蔵行きになっています。

追記の追記：そっか、そんな話をする前に、こういったことをRuby on Rails本体が結構やっていることを書くべきでした。
Railsって、実装そのものはかなりアクロバティックというか、強引なところがあります。上に書いたLoggerの件も然り。いくらformatを変えるための手段がなかったらかっていって、ふつうはサブクラスを作るとか、あきらめて専用クラスを実装するかするところを、いきなり書き換えちゃうんですからねえ。
というわけで、Railsの実装を見て、それを参考にRubyを書くのはわりと危険です。ご注意をば。