4

「getVisibleRegion」と呼ばれるインターフェイス関数のお気に入りのフレームワークの実装がいくつかの UI 機能を無効にしている (そして明らかにそれを復元するのを忘れていた) ことがわかりました。

私はフレームワークにバグを報告しましたが、これにより適切な設計について考えるようになりました: 単なる計算/取得操作を暗示する名前の操作に副作用があるのは、どのような条件の下で正当でしょうか?

実際の詳細に興味のある方へ: プラグインが Eclipse のコードの折りたたみを壊し続け、折りたたみバーが消え、「展開」したり、折りたたまれたコードを表示したりすることができなくなるというバグについての報告がありました。ソース コード ビューアーを表す型を持つ ITextViewer での getVisibleRegion() の呼び出しまでたどり着きました。現在、ITextViewer のドキュメントには、「ITextViewerExtension5 を実装するビューアーは、この契約を履行するために、表示される入力ドキュメントの一部を強制的に変更することができる」と記載されています。ただし、実際の実装では、これを少し自由に取りすぎて、投影 (折り畳み) を永久に無効にし、元に戻すことはありませんでした。

4

5 に答える 5

5

私が考えることができる最大の理由は、結果をキャッシュすることです。

于 2008-12-10T02:08:31.067 に答える
3

私はなしと言うでしょう。

于 2008-12-10T01:58:27.017 に答える
2

これは副作用とまでは言えないようなエッジケースかもしれませんが、計算の結果がオブジェクトにキャッシュされているのであれば、それは許容されます。それでも、呼び出し元に違いはありません。

于 2008-12-10T02:07:37.433 に答える
2

副作用が発生することが非常に明白な場合にのみ、私は言います. 簡単な例を次に示します。

  MakeMyLifeEasyObject mmleo = new MakeMyLifeEasyObject(x, y, z, default, 12, something);

  Object uniqueObjectOne = mmleo.getNewUniqueObject();
  Object uniqueObjectTwo = mmleo.getNewUniqueObject();

  System.out.println(uniqueObjectOne.getId() == uniqueObjectTwo.getId()); // Prints "false"

ここでの私の理論では、MakeMyLifeEasyObject には内部カウンター (DB テーブルの主キーのようなもの) があります。get の副作用があります。私はまた、次のようなアイデアを思い付くことができます：

  Object thing = list.getNextObjectAndRemoveFromList();

それも一理あるでしょう。

これらの注意点は、どちらの場合も、メソッドの名前を変更した方がよいということです。

最初のものはおそらく createNewUniqueObject() の方がよいでしょうが、2 番目のものは別の名前 (この場合は pop()) の方がよいでしょう。

上で示したような半ば不自然な例ではない場合、値の作成に長い時間がかかるか、かなりの頻度で使用される可能性があり、必要な場合に発生する唯一の副作用は、キャッシュの作成/更新であると言えます。スピードアップする。

この例は、一連の文字列を保持するオブジェクトです。束を連結する必要がある getThingToPrint() メソッドがあります。それが呼び出されたときにキャッシュを作成できますが、それは副作用になります。基になっている文字列の 1 つを更新すると、セットによってキャッシュが無効になります (または更新されます)。

あなたが説明したようなものですか？間違いなくバグのように聞こえます。それが良いアイデアとなるような状況は考えられません。これがバグではなく意図した動作である場合は、別の名前に変更する必要があります (つまり、disableThingAndGetVisibleRegion())。

于 2008-12-10T02:17:55.540 に答える
0

obj.getBusyDoingStuff()

于 2008-12-10T02:02:53.030 に答える