1

便利な方法がいたるところに散らばっていました。これらをいくつかのヘルパークラスにプッシュし、ヘルパークラスをレイヤースーパータイプのメンバーで保護しました。

Zend Viewに来るまで、すべてが順調に進んでいました。Zend Viewを拡張してレイヤーをスーパータイプにしましたが、保護されたメンバーをアタッチしようとすると、次のようにスローされます。

Zend Viewの例外:プライベートまたは保護されたクラスメンバーの設定は許可されていません。

第一に、なぜそのようなメンバーは許可されないのでしょうか?何か案は?第二に、あなたは過去にそれを回避しましたか?そして、それはどうでしたか?(フレームワークは、先頭のアンダースコアの存在によって保護されたメンバーを検出しているようです。これは少し行き当たりばったりで、簡単に回避できるようです)。

注-私はそれを回避すると言っているのではありません。私は他の人が過去に何をしたかを調べようとしています(奇妙な制約のように見えるため)。

特性を使用してヘルパーと関連するプロキシメソッドを各スーパークラスに取り込むので、これは私にとって重要なポイントです。ビューのためだけに別の特性を維持したくありません。あるいは、ヘルパーを各スーパークラスのパブリックメンバーにしたくありません。

ありがとうございました!

4

1 に答える 1

1

データのカプセル化。

開発者がフレームワークの一部であるViewプロパティを誤って上書きしないように、アンダースコアプロパティは主に許可されていません。

これにより、基本的にフレームワークのすべてのViewプロパティが保護され、開発者は、設定したいパブリックプロパティを自由に雨が降ることができます。

Zend Viewの作成者は、(1)プライベートクラスと保護されたクラスのプロパティを制御(および作成)することと、(2)パブリックプロパティを制御することの2つを確信できます。これにより、論理データのカプセル化と保守可能なクラスのオーバーロードが可能になります。

于 2013-04-01T22:13:13.070 に答える