0

ここでコア CS の質問: ガンマなどにリストされているデザイン パターンのうち、(もしあれば) モンキーパッチをカバーするのはどれですか? さらに、どのクラスの問題に対して、モンキーパッチとサブクラス化が適切ですか? コア ライブラリ クラスのバグにパッチを当てることはその 1 つですが、他にもありますか? stackoverflow でのモンキーパッチについては、多くの騒ぎと騒ぎを耳にします。ほとんどの人はそれについて強い不安を抱いているようですが、プログラマーとして、機能の一般的なビットをカプセル化し、それらをレールのオブジェクト モデルに含める機能が本当に気に入っています。

たとえば、thinkbot-paperclip を例にとると、今日存在するモンキーパッチのアプローチに対して、なぜそれをサブクラス化したいのでしょうか?

ありがとう、-エリック

4

1 に答える 1

1

モンキーパッチはデザインパターンではないと思います-コアクラス拡張は、彼らが無視しているように見える言語機能です。

残りについては、彼のブログのこの記事に関するJeff Atwood の見解をご覧ください。

彼の（そして私の）意見では、モンキーパッチの最大の問題は、既存のメソッドを変更すると、デバッグが非常に困難になる可能性があることです.私たち人間は、機械のように「あちこちの小さなスニペット」をすべて追跡することはできません。サブクラスは、より明確な分離を確立します。

したがって、モンキーパッチの個人的なルールは次のとおりです。

  • モンキーパッチなしで実行でき、問題なく動作する場合は、モンキーパッチを使用しないでください。
  • クラスに新しいメソッドを追加できますが、既存のメソッドを変更することはできません。
  • 非常に目に見える明白な方法でそれを行います。つまり、非表示の /myvendor/submodule/se.rb ではなく、/lib にある string_extensions.rb というファイルです。
  • ローカルである必要があります。ライブラリを使用しないクラスは影響を受けません。

さて、あなたの例に：ペーパークリップ。

  • 私の知る限り、ActiveRecord クラスにメソッドを追加しますが、既存のものは変更しません。
  • paperclip を使用するクラスにディレクティブを追加する必要has_attachmentがあります。そうしないと影響を受けません。

そのため、変更はローカライズされており、明白です (実際には、デバッグを改善has_attachmentすることができたと思います:の代わりに人間が読みやすくなっていますclass MyModel < Paperclip::ActiveRecordWithAttachment)。

この場合、サブクラスを使用する別のプラグインに加えてペーパークリップを使用できないため、サブクラス化も悪い考えです。レールは単一継承です。

そしてペーパークリップの場合、それは明らかに愛着とのhas_a関係であって、愛着との関係ではありませんis_a。サブクラス化の適切な使用法ではないと主張する人もいるかもしれません。

最後に、Paperclip では場合によってはサブクラス化が必要になることを指摘しておきます (ペーパークリップ プロセッサを作成するには、サブクラス化を使用する必要があります)。

于 2009-12-04T00:01:35.380 に答える