原著者の許諾を得て翻訳・公開いたします。Amp社のメンバーであり、RubyやElixirでの開発を行っています。Railsという書籍を執筆中です(現時点で45%↓)。state)」を効果的に導入するためのものです。ExchangeのよくできたQ&Aのリンクをご紹介します。簡単に言えば、(グローバルステートがあると)プログラムのステートが予測不可能になります。同じグローバル変数を共有しているオブジェクトが2つ(以上)あるとしましょう。ランダムさをもたらす不確定要素がモジュール内のどこにも使われていない前提条件においては、あるメソッドの実行前にシステムのステートが既知であれば、そのメソッドの出力は予測可能(したがってテスト可能)になります。Overflowの回答から引用いたします。CurrentAttributesがデメテルの法則にも反していることについては本記事では言及しません。ある日から突然、Currentがアプリのあらゆる場所で利用できるようになることを問題にしたいと思います。よいコードとは、メソッドや関数で利用できるようにする方法をコードで明示する(explicit)ものです。しかるに、CurrentAttributes機能はよくないコードであり、モデルでCurrent.userが利用可能になるまでの流れが明らかになりません。「魔法のように」そうしてくれるというだけです。私はいつもRailsの魔法で楽しんでいますし、これまでにも随分と助けられてきました。@collectionやポリモーフィックルーティングなどお気に入りの魔法はいくつもありますが、こうした魔法が優れているのはスコープが限定されているからです。コレクションをレンダリングできるのはビューであることも、ポリモーフィックルーティングを使えるのはコントローラやモデルやヘルパーであることも、ちゃんと察しがつきます。私がいくら魔法が好きだからと言っても、CurrentAttributesの魔法はあまりに強力すぎます。スレッドローカルなグローバルステートを導入すると、Currentに実際に値を設定するコードが覆い隠されてしまいますし、値の出どころも暗黙(implicit)になってしまうからです。「それ、コントローラで設定されるから」という反論もあるでしょう。コントローラがない場合はどうなるのでしょう。バックグラウンドジョブでは、あるいはテストではどうなるのでしょう。確かに、どちらの場合についても以下のようにCurrentで値を指定できます。