ホームページ  >  記事  >  バックエンド開発  >  (転記)PHPオブジェクト指向とPHPプロセス指向の長所と短所の比較

(転記)PHPオブジェクト指向とPHPプロセス指向の長所と短所の比較

WBOY
WBOYオリジナル
2016-06-13 13:24:55940ブラウズ

(譲)PHPオブジェクト指向とPHPプロセス指向のメリット・デメリットの比較

?? 多くのプログラミング言語では、どちらか一方のみを使用してプログラミングを行うことができます。つまり、PHP 言語は、自由に選択したり作成したりすることができます。 PHP オブジェクト指向と PHP プロセス指向が混在しています。 Web ページ自体の解析は非常に「手続き的」 (あるタグから別のタグに進む) であるため、今日の PHP プログラマーの大多数は手続き型アプローチを使用しています。 HTML への手続き型コードの埋め込みは簡単で自然なため、PHP プログラマーはこの方法をよく使用します。

?

PHP を初めて使用する場合は、おそらく PHP のプロセス指向スタイルでコードを記述することが唯一の選択肢です。ただし、PHP フォーラムやニュースグループに頻繁にアクセスする場合は、「オブジェクト」に関する記事を目にするはずです。オブジェクト指向の PHP コードの記述方法に関するチュートリアルもご覧になったことがあるかもしれません。あるいは、既製のクラス ライブラリをダウンロードして、オブジェクトをインスタンス化し、クラス メソッドを使用しようとしたことがあるかもしれません。ただし、これらのクラスがなぜ機能するのか、またはそれらのクラスを実装するために PHP オブジェクト指向メソッドを使用する必要があるのか​​はよく理解していないかもしれません。 。

?

「オブジェクト指向」スタイルを使用する必要がありますか? それとも「プロセス指向」スタイルを使用する必要がありますか? どちらの側にも支持者がいます。 「このオブジェクトは効率が悪い」「このオブジェクトは素晴らしい」といったコメントも時々聞かれます。この記事では、2 つの方法のうちどちらが絶対的に有利であるかを簡単に判断するのではなく、それぞれの方法の長所と短所を確認することを目的としています。

?

「オブジェクト指向」の基礎知識を知りたい場合は、Google 検索を使用してください。インターネット上には素晴らしい記事がたくさんあります。

このようなコードを書くのは誰ですか?

なぜこのトピックがフォーラム上での舌戦の火種になったのかを理解するために、各陣営のより極端な例をいくつか見てみましょう。 「プロセス狂信」と「オブジェクト狂信」を見てみましょう。彼らのアイデアに聞き覚えがあるかどうかを確認してください。

プロセスフィーバー

プロセス狂信は、この方法がより抽象的な実装を使用していないため、かつてクラスのコンピューター教師によって批判されました。 PHP のプロセス指向の視点「うまくいく!」をサポートしても、プログラミングのレベルやグレードは向上しません。卒業後は、速度とコードの改良に重点を置いたドライバー、ファイル システム、またはその他の低レベル プログラミングを作成する仕事に就く可能性があります。

「プロセス狂信」の極端な例は、オブジェクトや抽象化に対する抵抗です。彼らはプログラムをより速く実行する方法を常に考えており、他の人が自分のコードを読めるかどうかは気にしません。彼らはプログラミングをチーム活動ではなく競技として見なすことがよくあります。 PHP のほかに、彼らのお気に入りのプログラミング言語は C とアセンブリです。 PHP の世界では、PECL モジュールを開発し、効率的なコードを提供する場合があります。

オブジェクトの狂信

オブジェクトの愛好家は、いつでも PHP オブジェクト指向スタイルを使用してコードを記述することに熱心です。この方法を使用することがプログラムの実行効率に影響を与えるかどうかについては、あまり考慮されていません。時々、彼らは現実的なコードよりも抽象的なデザインコンセプトを楽しんでいるように感じます。彼らは通常、プロジェクト マネージャーまたはドキュメント ライターです。

オブジェクト愛好家は、抽象的な設計手法がなければ、依然として 0 と 1 を使用してプログラミングすることになると指摘しています。彼らは問題を説明するために疑似コードを使用することを好みます。極端な例は、効率が犠牲になることがあるとわかっていても、依然としてオブジェクトを使用するオブジェクト愛好家です。 PHP のほかに、彼らのお気に入りの言語は Java と Smalltalk です。 PHP の世界では、PEAR モジュールを開発し、十分に文書化された保守しやすいコードに貢献する可能性があります。

極端で皮肉なことはしないでください

フォーラムがいつも偏見で満ちている理由を知っていますか? 新しいものに対するあなたの経験と態度が原因かもしれません。プログラマーとして、私たちはこれらの偏見を常に認識し、新しいことを学ぶことにオープンである必要があります。

あなたのコーディング傾向はありますか?

PHP コードを記述するときにどのような好みや傾向があるかを考えてください。多くの場合、これらの好みはかなり微妙です。場合によっては、すべてのプロジェクトで同じ設定を使用する場合があります。私は個人的には「エレガント」の方が好きですが、ここでは「エレガント」なコードを定義するつもりはありません。これについては別の記事で説明する必要があります。ただし、理論化された好みが実際のプロジェクトに必ずしも当てはまるとは限りません。それどころか、偏見であることがよくあります。

理論傾向

? 最小限のコード行で完全なソリューションを提供します

? 問題レベルで問題を考える

これは良いアイデアだと思います。しかし、「コードの最小行数」を測定するにはどうすればよいでしょうか? コードのコメントを含めるべきでしょうか? 各行を区別するためにセミコロンのみを使用する必要がありますか? この考えは明らかに間違っています。

「問題レベル」とは何かを説明してください。これは、ソリューション内のすべての概念に対してクラスを作成する必要があることを意味しますか? それとも、問題の各部分を別のファイルに保持し、現実の問題に対応する複雑なファイル ツリーを構築する必要があるのでしょうか? – アイデアごとにファイルまたはクラスを用意します!

明らかに、これらの一般化は極端に解釈するとばかげたものになります。しかし、現実にはもっと微妙な証拠があります。プログラマーは、チームで作業しているときに、複雑で強力だがコメントされていないコードを 1 行挿入することがどのくらいありますか? これは、このコードのメンテナンスを引き継ぐ人々にとって間違いなく非常にイライラさせられます。それどころか、官僚的で独善的な優秀なプログラマは、インターフェイスやクラスを確立するために「暴走」することがよくありますか? そして、それらのインターフェイスやクラスは、実装を担当するプログラマを制限するだけでなく、効率と柔軟性も制限します。顧客が延長を求めたときの混乱。これらは、上記のそれぞれの傾向の微妙な証拠です。

実際の傾向

プロジェクトを開始するときは、まず実際のコーディングの目的と方向性を模索する必要があります。このプロジェクトの目標は何ですか? 考えられる答えは次のとおりです。

1. 迅速な開発、迅速なリリース

2. できるだけ速く走ります

3. 保守、改善、拡張が簡単

4. API を公開する

最初と 2 番目の方向は手続き型スタイルを使用する傾向があり、最後の 2 つは PHP オブジェクト指向スタイルを使用する傾向があります。

特定のアプローチがより効果的になるのはどのような場合ですか?

次に、各アプローチの実際の利点を評価してみましょう。

PHP プロセス指向のケース

PHP の手続き型プログラミングの利点の基本的な議論の 1 つは、PHP がインタープリタ型言語であるということです。つまり、他の言語とは異なり、実行可能パッケージにコンパイルされず、すぐに解釈されて実行されます。これはスクリプト言語であり、テキスト ファイルに保存されます (Zend コンパイル ツールを使用する場合を除く)。

PHP4 以前のバージョンでオブジェクト指向コーディングを使用することに反対するもう 1 つの理由は、PHP の以前のバージョンではオブジェクトの機能が適切に設計されていなかったことです。ラスムスはかつてこう言った。「それは思いつきだった。」これは、PHP4 以前ではオブジェクトの効率が問題であったことを意味します。しかし、PHP5 が登場すると、この状況は変わります。

次の 2 つの最も人気のある PHP プログラム、OsCommerce と PhpMyAdmin は主にプロセス指向のコーディングを使用します。構築も実行も高速です。どちらも当然ながら HTML を埋め込むアプローチを採用しています。

OsCommerce

OsCommerce は実際には多くのオブジェクトを使用しますが、ほとんどの機能は「プロセス」を通じて実装されます。私はかつて OsCommerce をハッキングして、顧客にとって非常に役立つカスタム機能を追加したことがあります。 OsCommerce の多くの処理コードはテンプレート化されたシステムを使用せず、多言語バージョンで設計されているため、開始するまでにある程度の時間がかかるため、このプロセスは非常に面倒です。しかし、それは機能しており、実際にすでに多くの電子商取引サイトで非常にうまく機能しています。 OsCommerce は、モジュールとプラグインを開発するためのフォーラムと開発フレームワークも提供します。したがって、現在では他の開発者によって多くの便利な機能モジュールが提供されています。

PhpMyAdmin

PhpMyAdmin によって直接使用されるクラスは、MimerSQLValidator クラスの 1 つだけです。これは、PEAR パッケージの Mail_Mime、Net_DIME、および SOAP に依存します。これは、目的を達成できる既製のコードを使用するという開発の都合によるものと考えられます。さらに、すべてが手続き型であり、HTML と PHP コードが混在しています。

PhpMyAdmin は、少数のデータ テーブルに対してそれほど複雑ではない処理を実行するために私がほぼ毎日使用しているツールです。場合によっては、クライアントにバックエンド管理ツールとして使用するよう勧めることもあります (もちろん、クライアントの権限は制限しています)。 PhpMyAdmin は非常に優れたパフォーマンスを発揮し、非常に高速です。場合によっては、一部のプロジェクトで PhpMyAdmin をバックエンド管理ツールとして拡張し、データ クエリ ステートメントのブックマークなどの新機能を使用して顧客や編集者に簡単に表示したいことがあります。新しいバージョンが登場するたびに、PhpMyAdmin はますます便利で強力になります。 ソフトウェア開発ネットワーク

PHP プロセス指向の概要

プロセス指向スタイルを使用する上記 2 つのプログラムには、非常に優れたドキュメントとコード コメントが含まれています。 OsCommerce が提供する開発フレームワークにより、保守性と拡張性が向上します。ただし、どちらも API を提供しておらず、プログラムを他のシステムに拡張することはできません。

OsCommerce を請求プログラムに統合したい場合は、PhpMyAdmin を顧客向けのバックエンド管理ツールに拡張するなど、多くの時間と労力がかかります。ただし、設計の目的から判断すると、それぞれの分野で非常に優れたパフォーマンスを発揮します。

PHP オブジェクト指向のケース

オブジェクト指向スタイルを支持する人々の意見は、拡張性とカプセル化に焦点を当てています。オブジェクト指向でコードを書くだけではコードは文書化されませんが、コードを文書化することは奨励されます。また、拡張を容易にするために、API を作成することもできます。 PHP5 は、オブジェクト指向プログラミングをさらに楽しくすることを約束します。私はこれを冗談めかして PHP の「Java 2」バージョンと呼んでいます。これは、インターフェイス、オブジェクト指向モデル、try-catch ステートメントなど、Java の多くの機能が統合されているためです。ただし、オブジェクト指向のサポートがなくても

多くの優れたオブジェクト指向アプリケーションが強力な PHP4 に今でも登場しています。

スマーティ

Smarty は、複雑なフォームを持つテンプレートベースのサイトを構築するために使用されます。最近、私は完全に「スキン化」できるオンライン試験システムを作成しました。これは、基礎となるコードや機能を変更することなく、サイト全体の外観、インターフェイス、スタイルを完全に変更できます。デザイナーが新しいインターフェイスを簡単に設計できるようにするために、Smarty タグ ライブラリの拡張としてカスタム タグ ライブラリを設計しました。次のように簡単に挿入できます:

[navigationhorizo​​ntal Separatedby"|"]

ページの上部には独立したナビゲーションがあります。 Smarty は、変数に含まれるデータを表す非常に強力なメカニズムをすでに提供しているため、これは、より複雑な Smarty タグをスキン タグにマッピングする単純なプロセスです。

Smarty はクラスとしてカプセル化されており、そのメソッドが十分に文書化されているため、テンプレートを使用するプロセスは驚くほど簡単に拡張できます。同時に、Smarty は、使用する変数のみを Smarty テンプレート メソッドに明示的に渡すことを強制することで、PHP 環境変数の保護層も提供します。このアプローチは、Smarty テンプレートのデザイナーとプログラマーの間に安全で信頼できる作業関係を確立するのに役立ちます。

FPDF

FPDF は非常に優れたツールです。 pdflib の API の変更に混乱している場合、商用ソリューションにお金を払う気がない場合、または共有ホスティングの制限により拡張モジュールを使用できない場合は、この無料の純粋な PHP で構築された PDF 生成ツールの使用を検討してください。

このクラスは文書化されており、PDF 内でテキストと画像をレイアウトする方法の良い例が多数含まれています。上記と同じオンライン学習サイトで、FPDF を使用して、TrueType フォントと 300 dpi の精度の画像を使用して PDF ファイルを動的に生成しています。 PDF 自体のダウンロードには数分かかる場合があるため、PHP で FPDF クラスをインスタンス化し、PDF を操作するのに余分な時間はかかりません。実際、PDF を動的に生成して配信するのは、低速なネットワーク接続を介して静的な PDF ファイルを配信するのと同じくらい時間はかかりません。これはすべて相対的なものです。また、FPDF はクラスベースであるため、拡張することができます。実際、いくつかのクラス メソッドは存在しますが、まだ完全には実装されておらず、サブクラスで独自のコンテンツ (カスタム ヘッダー要素やフッター要素など) を構築する際のガイドとなるフレームワークとしてのみ機能します。

PHP オブジェクト指向の概要

Smarty と FPDF はどちらも、メイン クラスを拡張するための十分に文書化された API を提供します。これは、クラス内でメソッドとデータを編成する必要性を示しています。関数やグローバル変数を使用して同じ機能を実現できる場合もありますが、これを拡張するのは簡単ではありません。さらに、オブジェクトの使用は、PDF または HTML ドキュメントのスタイルを追跡および維持するのに非常に役立ちます。同じデータを異なる形式で発行で​​きます。 Smarty と FPDF はどちらも、オブジェクトを使用して柔軟で実用的なクラス ライブラリを構築する優れた例です。

なぜ両方の方法が必要なのでしょうか?

情熱的なプログラマーの話に戻り、私たちは彼らを称賛し始めます。

1. Smarty と FPDF の実用性と拡張性を高く評価します

2. osCommerce と phpMyAdmin の速度と優れたパフォーマンスに感謝します

この評価には、PHP の基本的な開発も含まれています。 PECL と PEAR はどちらも多くの賞賛と批判を受けています。これら 2 つのプロジェクトは、PHP における手続き型プログラミングとオブジェクト指向プログラミングの違いを明確にする良い例になると思います。

PECl は、速度とシンプルさに重点を置き、C およびプロセス指向のメソッドで開発された PHP 用の拡張ライブラリを提供します。通常、これらは既存の LGPL ソフトウェアからの移植であり、多くの興味深い機能が PHP に追加されています。結局のところ、PHP は C で書かれています。

PEAR は、Excel テーブルの作成や DNS レコードの変更など、多くの興味深いクラスに貢献してきました。 PEAR クラス ライブラリを使用すると、時間を大幅に節約でき、PHP に詳しくなくても、「よくわからないけど使える!」という開発が可能になります。

概要

この記事が、PHP オブジェクト指向と PHP プロセス指向という 2 つのプログラミング方法についての理解を深め、さらに重要なことに、より具体的な詳細を調べるよう促すことを願っています。ご自身のアイデアを持ち、実際の開発でプロジェクトの開発傾向をテストし、より実践的な事例をまとめ、この記事に遠慮なくコメントを書いていただければ幸いです。

つまり、それぞれの方法にはそれぞれ利点があるため、議論に巻き込まれるよりも、そのままにして実際のコードを作成する方が良いのです。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。