なぜゲッターではないのですか?そして、それはカプセル化の原則とどのように組み合わされましたか? 安全ですか?
Upd:
はい、約Request
です。安全性:コード内の誰でも(リスナーを使用して)実行できることを意味します$request->attributes = null;
なぜゲッターではないのですか?そして、それはカプセル化の原則とどのように組み合わされましたか? 安全ですか?
Upd:
はい、約Request
です。安全性:コード内の誰でも(リスナーを使用して)実行できることを意味します$request->attributes = null;
RequestオブジェクトとResponseオブジェクトについて話している場合は、数日前に Symfony 開発者メーリング リストでこれについての議論がありました。ここでご覧 ください.
なぜゲッターではないのですか?これに決定的な答えがあるかどうかはわかりませんが、主に個人的な好みに基づいた決定だと思います.
カプセル化を破りますか?この特定のケースについては、私の意見ではありません。私の推論は、現時点では、現在公開されているさまざまなオブジェクトに対して特別なロジックが実行されていないということです。したがって、最終的には、getter を介してオブジェクトを取得し、直接読み取りまたは変更することになります。パブリック プロパティを使用してオブジェクトを取得する場合と大きな違いはありません。
// With Getters
$parameterBag = $request->getQuery();
$parameterBag->get('key');
// With Public Properties
$parameterBag = $request->query;
$parameterBag->get('key');
プロパティに特定の値または形式があることを確認する必要がある場合は、カプセル化を適用する必要があります。たとえば、コスト プロパティを持つクラスがあり、このプロパティが負になることはないとします。そのため、コスト プロパティが public の場合、次のようにして負の値に設定できます$receipt->cost = -1;
。ただし、クラスを非公開にし、クラスのユーザーがセッターを介してのみ設定できる場合は、セッター コードで特別な検証を行うことにより、コストが 0 を下回らないようにすることができます。
この場合、コレクション オブジェクト、正確には ParameterBag オブジェクトについて話しています。このオブジェクトに特別な要件があるとは思いませんが、間違っている可能性があります。したがって、私にとっては、パブリック プロパティを介してこれらのプロパティにアクセスできるのは正しいことです。
ゲッターを支持する主な議論は、ゲッターが使用されるフレームワークの他の部分とより一貫性があるということです。ただし、ゲッターはパブリック プロパティと共存できます。
結論として、この特定のケースでは安全だと思います。パブリック プロパティは、それが有益であると思われる特別な場合にのみ使用し、それが正しい場合にのみ使用する必要があります。
すでにカプセル化されているものをカプセル化するポイントは何ですか? つまり、このプロパティのそれぞれは、カプセル化された parameterBag インスタンスです。