5

PHPでクラスを使用する理由を知りたいです。すべてのオープンソースで、クエリを実行するためにクラスを使用しているのを見てきました。mysql_query()結果の取得、クエリの挿入などにクラスを使用することを意味します。これは一貫性と高速化のために使用されると思いますが、オブジェクトリンクを作成するのではなく、を使用してクエリを実行する$db->queryと、2番目のものと比較して高速に実行されます。関数に移動してそこで実行し、その後結果を返しますが、その場合はmysql_query()同じ場所でクエリを実行します。だから私はmysql_query()速く実行すると思います。では、なぜクラスとオブジェクトを使用してクエリを実行するのでしょうか? クラスを使用する利点は何でしょうか?

4

5 に答える 5

14

カプセル化: クラスは、コードと関連データを一緒に含む有用なパケットであり、他のすべてから分離されています。これにより、正確な変数を検索せずに、既存のコード/データと衝突することなく、簡単に移動できます。

もちろん、クラスには他の用途もありますが、PHP のようなスクリプト環境では、それが最大の利点だと思います。

編集:「継承はカプセル化よりも強力である」という議論に反対されました。これはスクリプトと Web のシナリオには当てはまらないと思います。その理由を説明してみます。

初め、Web ページの寿命は要求/応答のペアであり、理想的には 1 秒未満です。通常、状態は外部エンティティ (セッション、Cookie、DB など) に保存されます。ページの有効期間は非常に短いため、Web ページ コードで可能な状態は、たとえばファット クライアントよりも少なくなります。ほとんどの場合、実行中のコードの小さなバーストであり、継続的に作業を完了します。おそらく Web ページは、単純さと設計パラメーターの数という点で、コンソール アプリケーションに匹敵します。フォーム内の入力パラメーターの数はギガバイトになる場合がありますが、UI 要素と入力パラメーターの間の関係は、画面の解像度、つまりユーザーが一度に入力できる内容に対する全体的な能力に制限されます。したがって、ほとんどの場合、入力パラメーターの数が少なく、状態の数が少なくなります。もちろんコンビナトリアルで」

Web アプリケーションの入力と出力はほとんど同じです。入力はクエリ パラメータまたはフォーム データであり、出力は HTML ドキュメントです。したがって、有効期間が短いため、入力処理と出力の生成コードは、Web ページ用に同じように形作られ、設計されています。この図では「ビジネス ロジック」の大部分を省略していることに気付きました。ただし、コードのこれらの部分では、「ポリモーフィズム」や「継承」などの OOP の気の利いた機能を使用しないようにしましょう。そのための非常によく知られた、長い間研究された、実用的で非 OOP のパターンがあります。「ポリモーフィズム」や「ビジター パターン」などを使用してクエリ パラメータを解析する新しい方法を発明するのは、少なくとも愚かなことです。

データ アクセスも既存のライブラリによって実行され、「継承」や「ポリモーフィズム」などの贅沢はそこでは役に立ちません。クラスを引き続き使用できますが、それは単にカプセル化になります。T-SQL または PL/SQL コードを記述するために MySQL コードを継承または再利用することはできません。完全な交換が必要です。ああ、あなたSELECT * FROM tableは「受け継がれる」かもしれないし、可能性を考えてみてください。

今、私たちは何を残しましたか？はい、ビジネスロジックです。ビジネスロジックも情報処理の短いバーストであることはすでに述べました。PHP コード自体には永続的なビジネス状態はありません。The Web の要件により、ほぼすべてのビジネス オペレーションに 1 秒もかからないことがわかっています。したがって、経験できる状態は、本格的なアプリケーションよりもはるかに少なくなります。典型的な Web アプリケーションでは、ほとんどの場合、アトミックで分離されたビジネス オペレーションが進行しています。

さて、デザインに戻りましょう。ページが次の部分で構成されていることがわかっています。

  • 入力
  • ビジネスの論理
    • データアクセス
  • 出力

入力、データ、出力はポリモーフィズムと継承の範囲外です。これが私たちの最終的な写真です：

  • 入力処理
  • ビジネスの論理
    • データアクセス
  • アウトプット生産

ビジネス ロジックはアプリの最大の部分になる可能性がありますが、それでも Web アプリケーションの 1 秒のウィンドウ内に収まる必要があるため、小さい、つまり短命である必要があります。

はい、スーパーコンピューターは 1 秒で多くのことを実行できますが、まだ大多数の一般的なシナリオについて話しています。何が一般的ですか？CRUD は一般的です。これが、Ruby on Rails と Active Record パターンが大きな成功を収め、人気を博した理由です。CRUD という 1 つのことで生産性が向上したからです。

設計の複雑さは、関連するデータ要素と操作の数に比例します。また、操作の大部分は CRUD であると想定しているため、固定数の操作と少数の入力パラメーターがあり、小さな問題空間があります。

例外はありますが、ほとんどの場合、小さな問題空間の設計は複雑でありながら優れたものにはなりません。膨大な量のデータ ポイントがあり、背後で過剰な冗長性が発生しない限り、Web ページのデザインで継承を使用できる可能性はほとんどありません。繰り返しますが、ほとんどの場合、それは粗雑な CRUD です。

2つ目 (忘れた場合に備えて最初に 1 つ目があります)、Web アプリのパフォーマンスは重要です (重要ではないにしても) -「1 秒」を覚えておいてください-スクリプト環境では 2 倍重要です。

オブジェクト指向のパラダイムは、有用性とパフォーマンスを同時に実現するための非常に重要な低レベルのメカニズム、つまりポインターの間接化に依存しています。CPU がポインタを読み取り、それが指すアドレスにジャンプする能力は、アドレスに直接ジャンプする場合とほとんど違いがありません。そうすれば、正しい関数呼び出しのルックアップに使用される仮想メソッドテーブルを使用でき、コンパイラーはオブジェクトの「some()」メソッドを正確な型を知らなくても呼び出すことができます。クレージー・ホース。

その夢はスクリプトの世界で終わります。命令をネイティブに実行する CPU がありません。PHP コンパイラーによって生成されたバイトコードがあり、それは PHP インタープリターによって解釈されます。CPU とは異なり、PHP インタープリターは、バイトコードに関係なく、抽象化、クラス、型などのより高いレベルの概念を処理する必要があります。CPU の単純なポインター間接化は、PHP の複雑な一連の操作です。操作を解析し、操作を理解し、おそらくいくつかの健全性チェックを行い、最後に別のバイトコードのセットで実行します。

したがって、スクリプトの世界での継承のオーバーヘッドは、ネイティブ環境よりも桁違いに遅くなります。

もちろん、利益が損失よりも大きい限り、それは許容されます。また、アップグレードやクラスタリングなどの他の方法でパフォーマンスの低下を回復できることを考えると、問題はないようです。それは確かに真実であり、これが私の最終的な声明です：

Web アプリケーション開発のほとんどのシナリオでは、継承/ポリモーフィズムを呼び出さなくても、同等に保守可能で、同等に再利用可能で、おそらくよりパフォーマンスの高い設計を実現できます。したがって、カプセル化は、継承ではなく、PHP で最も一般的で最大の利点です。

于 2011-02-02T09:21:40.417 に答える
4

クラス、つまり OOP (オブジェクト指向プログラミング) を使用する理由はたくさんあります。

  1. コードの再利用
  2. 継承
  3. 容易な保守性
  4. カプセル化

他にも多くの理由があります.OOPを使用することの利点/欠点を調べてください.

于 2011-02-02T09:22:13.010 に答える
2

使用するときは、前に と を使用mysql_query()して DB に接続する必要がmysql_connect()ありmysql_select_db()ます。

毎回あなたはmysql_connect()それにコストをかけます。
したがって、一度作成mysql_connect()して保存し$linkます。そして、このリンクをすべてに使用してくださいmysql_query("...", $link)

オブジェクトでも同じですが、クラスのインスタンスを作成し (DB への接続を作成するため)、リンクを持つオブジェクトを使用する方がより洗練されています。

DB パスワードを変更する場合は、クラス内で一度だけ変更します。
MySQL を PostgreSQL に変更する場合は、コードを 1 回、クラスだけで書き直します。アプリの残りの部分には影響しません。

于 2011-02-02T09:41:02.703 に答える
2

かかった時間

$db->query()
mysql_query()

ほぼ同じです。

クラスを使用してコードを高速に実行するのではなく、それらを整理します。

プロジェクトが大きくなるにつれて、コードの管理が難しくなります。

オブジェクトをオブジェクト化すると、そのオブジェクトをインスタンス化して再度使用することができます。また、コードが他のオブジェクトと混同される可能性が少なくなります。

オブジェクト指向のコーディング方法は、コードをエレガントに管理し、より良い結果を生み出すための最も簡単でベストな方法です。

于 2011-02-02T09:23:17.067 に答える
0

@frbry が言ったように、抽象化のためにクラスを使用します。複雑さを管理および軽減するには、抽象化が必要です。操作とデータを「抽象化」できると、他のことを行うときに「分離され抽象化された」ものの実装について考えずに、他のことに集中することができます。

また、コードの他の部分への影響を小さくして将来的にシステムを変更し、システムの複雑さを軽減するのにも役立ちます。

1986 年の非常に優れた MIT の講義があり、一般的に LISP プログラミングに関するものですが、プロシージャ (または彼らが呼ぶブラック ボックス) で物事を抽象化する必要がある理由も非常によく説明されています。複雑さの軽減について。

リンクは次のとおりです。 http://www.youtube.com/watch?v=2Op3QLzMgSY

于 2011-02-02T09:26:17.830 に答える