1

質問を例で説明します.zendフレームワークでは、ビュークラスに機能を追加したい場合、ヘルパークラスと呼ばれるものを使用できます。
ヘルパー クラスは、各ビューで使用可能になる 1 つのメソッド (クラスの名前と同じ) を持つクラスです (リフレクションにより、ヘルパー メソッドはビュー メソッドによってラップされます)
。そのような各ヘルパーとリフレクションで遊ぶいくつかの追加のインクルード。どちらもパフォーマンスに影響します。

私の考えは、ビューに追加したいメソッドごとにヘルパーを開発する代わりに (それぞれ別のファイルに)、C スタイルの関数 (つまり、クラスの静的メソッドではなく、実際の関数) のリストを使用して 1 つのヘルパーを作成することでした。 View クラスでのみ使用されます (View ヘルパーは View にのみ含まれるため)。

したがって、これはいくつかのプロシージャルとオブジェクト指向を混合していますが、パフォーマンス上の利点は目に見えます。とにかく、ヘルパーは通常、状態を維持する必要のない単一のメソッドです...

ある人はこう言うだろう: 「手続き型を使えばパフォーマンスが向上する」, いいえ, 私は OO の利点をよく知っています. ただし, この小さな問題を除い
て.

4

3 に答える 3

1

最初：OOPは手続き型のサブセットである構造化プログラミングのサブセットであるため、あなたが暗示するように「パラダイムワイズ」には進んでいません。（「パラダイム」、なんて醜くて使い古された言葉）

2 つ目: OOP は設計スタイルであり、言語機能ではありません。メソッドの代わりに関数を使用しても、(概念的な) カプセル化を維持している限り、プログラムの OOP は少なくなりません。

3 番目: PHP のほとんどの OOP コードでさえ、あるレベルで組み込み関数を使用する必要があります。したがって、ほぼ定義上、関数の使用は「アンチ OOP」にはなりません。

4 番目: ええ、OOP は最高のデザイン スタイルの 1 つですが、「ビジョンに忠実であり続ける」ことに美徳はありません。結局のところ、それらはすべてツールチェストのツールです。選択した言語の OOP コンストラクトがこの特定のインスタンスに必要なものを提供できない場合は、他のトリックを使用して機能させます。コードの保守性について心配している場合 (そうでない人はいますか?)、オブジェクトによって提示されるインターフェイス内の「ハッキーな」部分をカプセル化して、リークしないようにします。

于 2009-03-30T03:28:09.880 に答える
1

あなたの質問に答える唯一の方法は、それぞれの設計上の決定について長所と短所を示すことです。

一般に、状態制御の関与が最小限である場合、ステートレスな処理、ワンショットのデータ変換の場合は、手続き型の設計が最適です。手続き型処理の例としては、あらゆる種類の数学関数、文字列変換、配列変換、ダイレクト メモリ アクセスなどがあります。

OOPは状態制御に最適ですが。UI 要素 (何百万もの教科書の例)、ソケット プログラミング (オープン、リスニング、クローズ、その他の状態)、プロトコルの実装などに OOP を使用することは素晴らしいことです。複数のインスタンスとステート マシンを含むものはすべて、見事に実装されます。

そのため、単純な処理用のワンショット関数とクラス内の複雑な状態制御を組み合わせることが一般的です。クラスのメソッドは、内部データ処理に関数を使用します。

何かを一緒にハッキングすることは、短命で非生産的なコードでうまくいくかもしれません。しかし、複数回のアップグレードの後、コードのスパゲッティ ソースを探すことになるかもしれません。その場しのぎのコーディングとは対照的に、コードを慎重に設計することは常に良いことです。

もう 1 つの側面は、フレームワークでの一般的な慣行です。Zend フレームワークで混合実装 (単純な変換のための OOP と関数型) を使用することが一般的である場合、そうしない理由はほとんどありません。そうでない場合は、1 つのアプローチに固執することをお勧めします。そうしないと、保守性の問題に直面し、他の人がコードを理解するために何時間も何日も費やさなければならなくなります。

また、何をするにしても、あらゆる技術的な制限を調査する必要があります。

  • コンパイラ（インタプリタではなく）とリンクが関係している場合は、そこに問題がないことを確認してください
  • コードがモジュール (ライブラリ) に分割されている場合は、混合によって互換性が失われないことを確認してください。
  • パフォーマンスに関する懸念がある場合は、それらを定量化します。そうすれば、決断が楽になるかもしれません
  • 多くのテスト アプリケーションを実行して、選択内容を確認します。予期しないクラッシュ、開始/停止の遅延、データの破損、処理を完了するためのフープの飛び越しなどは、選択が最適ではないことを示しています。理由を知ることは、何を知ることと同じくらい重要です。
于 2009-03-30T03:58:31.787 に答える
0

非機能要件に従って設計する必要があります。たとえば、スループットが目標である場合は、パフォーマンス パスを選択する必要があります。しかし、保守性が目標である場合は、読みにくいパフォーマンス最適化コードをすべて入れるよりも、コードを読みやすくする必要があります。

フレームワークは、物事を決定する余地を残します。OOP 自体は単なる概念です。したがって、オブジェクト指向プログラムで C スタイルの関数を使用することは罪ではありません。それが適切な場合は、それを選択してください。

于 2009-03-30T03:53:47.917 に答える