0 
class HueHue {
    private $hue;

    public function show(){
        echo $this->hue;
    }

    public static function parse($string){
        // parse it all
        $HueHue = new HueHue();
        $reflector = new ReflectionClass($HueHue);
        $hue = $reflector->getProperty('hue');
        $hue->setAccessible(true);
        $hue->setValue($HueHue, $parsed_string);
    }
}

これは「悪い」ですか？を作成するよりもこれが本当に好きpublic function setHue($parsed_string)で、 parse() は静的でなければなりません。なぜならnew、設定して取得するのが嫌いだからです...

最終的なゲームはただすることであり、私は本当に設定可能にHueHue::parse('something here')->show();なりたくありません.private $hue

フィードバックをいただければ幸いです。

4

2 に答える 2

5

これは「悪い」ですか？

あなたのしていることは悪くありません。それは世界で最もクリーンなものではありませんが、同時に問題を解決するのであれば、それは良いことです. ただし、@Xeoncross の変更を加えると、少しクリーンになり、リフレクションが回避されます。

しかし、あなたがそれをしている理由は悪いと私は主張します。

出力用に文字列をフォーマットするためだけにオブジェクトを作成している場合は、そもそもオブジェクトを使用する理由を再考することをお勧めします。用途の大部分が次の場合:

HueHue::parse($hue)->show();

それでは、オブジェクトのステップをスキップする関数を 1 つだけ作成してみませんか?

function parseHue($hue) {
    // parse it
    return $parsed_hue;
}

次に使用します：

echo parseHue($hue);

または、何らかの理由で値オブジェクトが必要な場合 (質問には示されていません)、パーサーを別のオブジェクトに分割し、キューをコンストラクター パラメーターにします。

class Hue {
    private $hue;
    public function __construct($hue) {
        $this->hue = $hue;
    }
    public function show() {
        echo $this->hue;
    }
}

class HueParser {
    public function parse($string) {
        // parse it!
        return new Hue($parsed_hue);
    }
}

デカップリングの理由は、パーサーをポリモーフィックに切り替えることができるようになったためです。したがって、パーサーのコンシューマーの単体テストは、モックと交換できます。

関心の適切な分離を維持していることは言うまでもありません。そのため、パーサー ロジックを更新する場合 (たとえば、新しい形式を考慮して)、コンシューマー (パーサーを呼び出す人) またはエンド ユーザー (Hue オブジェクトを取得するユーザー)...

于 2013-04-22T14:03:28.023 に答える
1

同じクラスならリフレクションは必要ありません。

class HueHue {
    private $hue;

    public function show(){
        echo $this->hue;
    }

    public static function parse($string)
    {
        $HueHue = new Static();
        $HueHue->hue = $string;
        return $HueHue;
    }
}

HueHue::parse($hue)->show();
于 2013-04-22T13:43:24.640 に答える