2

私はここでPythonで作業しています（実際には名前によるパスです）が、メソッドパラメーターが同様に動作する限り、アイデアは言語に依存しません。

私がこのような機能を持っている場合：

def changefoo(source, destination):
    destination["foo"] = source
    return destination

そしてそれをそのように呼びます、

some_dict = {"foo": "bar"}
some_var = "a"

new_dict = changefoo(some_var, some_dict)

new_dictの修正バージョンになりますが、変更some_dictもsome_dictされます。

私の例のdictのような可変構造はほとんどの場合同様に小さく、パフォーマンスは問題ではないと仮定します（アプリケーションでは、抽象オブジェクトを取得し、さまざまなサービスのSOAP要求に変更します。ここで、SOAP要求は順序を取ります各サービスのデータを再フォーマットするよりも桁違いに長い）、これは大丈夫ですか？

これらdestinationの関数（いくつかありますが、私の例のように単なる効用関数ではありません）は常に変更可能ですが、明示的にしたいと思います。関数の戻り値は、渡したパラメーターに対する決定論的計算の結果を表します。 in。パラメーターを使用するのは好きではありませんが、可変構造を関数に渡すときにPythonでこれを回避する方法は実際にはありません。私が熟考したいくつかのオプション：

  • 元のパラメーターを保持するために、変更されるパラメーターをコピーする

    パラメータを変更するすべての関数でパラメータをコピーする必要があります。これは面倒で、多くを複製しているように見えます。さらに、実際にオリジナルが必要になることはないと思います。すでに持っていた変異オブジェクトへの参照を返すのは面倒なようです。

  • イン/アウトパラメータとして使用するだけです

    私はこれが好きではありません、関数が何をしているのかすぐにはわかりません、そしてそれは醜いと思います。

  • パラメータを自動的にコピーするデコレータを作成します

    やり過ぎのようです

だから私は大丈夫ですか？私は何かを隠しているような気がします。将来のプログラマーは、関数の呼び出し方法に基づいて元のオブジェクトが保持されていると考えるかもしれません（元のオブジェクトを変更するという事実に頼るのではなく、結果を取得します）。しかし、私はまた、選択肢のいずれかが厄介になると感じています。より好ましい方法はありますか？ソフトウェアの動作方法により、抽象データを表すクラスにミューテイタースタイルのメソッドを追加することは実際にはオプションではないことに注意してください（そのデータ構造をすべてのサービスの対応するSOAP構造に変換するメソッドを追加する必要がありますそのデータも送信します-現在、変換ロジックはサービスごとに個別のパッケージに含まれています）

4

1 に答える 1

1

このような関数がたくさんある場合は、辞書をラップしてその場で変更する小さなクラスを作成するのが最善の策だと思います。

class DictMunger(object):
    def __init__(self, original_dict):
        self.original_dict = original_dict

    def changefoo(source)
        self.original_dict['foo'] = source

some_dict = {"foo": "bar"}
some_var = "a"

munger = DictMunger(some_dict)
munger.changefoo(some_var)
# ...
new_dict = munger.original_dict

オブジェクト自体を変更することは一般的に想定されており、読みやすくなっています。

于 2011-05-28T06:38:28.733 に答える