1

それで、他のクラスで構成されているクラスがあるとしましょう。

class HttpRequest
{
public $session = new Session();
// .. the rest of the HttpRequest code
}

ここで、HttpRequestクラスを介してSessionクラスにアクセスしたいので、compositionを使用します。しかし、これは、すべてのプロパティを保護し、setterメソッドとgetterメソッドを介してアクセスする必要があるというOOPカプセル化またはデータ隠蔽の法則に違反しますか？

これは間違っていますか：

$request = new HttpRequest();
$request->session->set('id', 5);

または私はこれを使用する必要があります：

$request = new HttpRequest();
$session = $request->getSession();
$session->set('id', 5);

カプセル化は、プロパティを保護する必要があることを示しています。では、内部クラスへのアクセスを提供するにはどうすればよいですか？適切なOOPに関する限り、最初の例は間違っていますか？

4

3 に答える 3

1

オブジェクトへの直接アクセスを許可しない正当な理由があります。

  • オブジェクト自体の外部でオブジェクトを操作できるようにします。プロパティをパブリックにすると、コードのどの部分でもHttpRequestクラスの$ sessionが上書きされる可能性があり、それを追跡するのに苦労することになります。データ保護の観点からのカプセル化は、オブジェクトのメソッドのみがオブジェクトを直接変更できるようにするためにあります。
  • その変数が設定されていない場合を適切に処理できます。何らかの理由で$sessionがクラスに設定されない場合、メソッドを呼び出そうとするとすぐに致命的となります。ゲッターでラップすると、その状態をチェックして、クラスの新しいインスタンスをその場で作成できます。
  • 真の「OO」パラダイムに従う

ただし、場合によっては、これを実行しても問題ないと思います。特に、プロパティが常に設定されることがわかっている場合（そして、プロパティが設定されない唯一の方法は、オブジェクトを使用するためのサポートされている方法ではありません）。

また、プロパティへのアクセス方法によっても意味があります。Symfony2はこれをRequestクラスで使用します。その場合、「query」、「post」、および「request」変数はすべて「ParameterBag」（グローリファイド配列）であるため、自然に感じられます。ただし、それらはSessionオブジェクトのゲッターを公開します-おそらくそれのユースケースのためです。

つまり、変数をどのように使用するかによって異なります。この特定のケースでは、それはそれほど重要ではないと思います。

于 2012-11-12T00:27:22.070 に答える
0

私はあなたの最初のオプション（compositionを使用するもの）が好きで、カプセル化されているように見えます（関数が設定される理由はわかりません）が、「コンポーネント」オブジェクトの関数を介していくつかの属性を変更していると思います。セッション」、そのパターンは「委任」としても知られています。

一方、カプセル化を使用する場合、「パブリック」を使用することはできません。これにより、すべてのユーザーが変更できるようになります。このため、setterまたはgetterを使用するか、コードで「set」を使用します。

于 2012-11-12T00:43:19.403 に答える
0

私はこれが古いことを知っていますが、私はこれらのどちらも使用しません。HttpRequestオブジェクトは本当にSessionオブジェクトを保持する必要がありますか、それともSessionオブジェクトをそれを必要とするHttpRequestオブジェクトのいくつかの関数に渡すことができますか？HttpRequestにこのオブジェクトを保存させる強力なケースはありますか？

于 2013-12-28T15:27:57.637 に答える