PHP+Java 開発経験: オブジェクト指向になりすぎない_PHP チュートリアル-PHPチュートリアル-php.cn

PHP+Java 開発経験: オブジェクト指向になりすぎない_PHP チュートリアル

WBOY

リリース： 2016-07-15 13:26:27

オリジナル

781 人が閲覧しました

オブジェクト指向と言えば、現在多くの言語にいくつかのオブジェクト指向があります。 Java は伝統的なオブジェクト指向言語であり、PHP にもある程度のオブジェクト指向がありますが、あまり優れていません。特定のプロジェクト (この記事は Web 開発プロジェクトです) では、完全にオブジェクト指向であることが最善の選択ではない場合があります。この記事の著者は最終的に PHP+Java のモデルを選択し、彼自身の経験のいくつかを共有しました。

私は高校時代に C++ に触れ、より早くオブジェクト指向の考え方を受け入れました。オブジェクト指向の考え方は人間の考え方に近く、カプセル化や継承などの機能により一部の作業が簡素化されることがよくあります。最も重要なことは、アイデアがより明確に見えることです。私はオブジェクト指向の考え方を強く信じていましたが、ある日、WEB プロジェクトで混乱してしまいました。

私の以前の仕事も WEB 開発に関連しており、通常、プロジェクトはインターフェイス、実装、サービス層、DAO 層でした。時間が経つにつれて、私はこのパターンに慣れてきました。その後、私は自分のウェブサイトを作成し始めました（自分で運営します）が、これもこのモデルに従いました。それを取り出して実行できるようになるまでに時間がかかり、問題が発生しました。ご存知のとおり、ポータルのようなもの、特に成長段階にある Web サイトは、しばしば変更や拡張に直面することがあります。これは、書かれたプログラムのセットを継続的に使用できる、安定モードで動作するエンタープライズプロジェクトや Web サイトとは異なります。しかし、JAVAのものを変更するのは少し面倒です。

第一: プロジェクトでは多くのインターフェースが使用されており、ビジネスの変更時にインターフェースに触れる必要が生じることがよくあります。需要が満たされていないからだと言う人もいるかもしれません。そうお考えになるかもしれませんが、前提があります。需要は 1 つのステップで満たすことができません。そうしないと、需要分析が完了すると、花は枯れてしまいます。この古典的なプロセスを思い出してください。機能を追加するには、まずサービスインターフェイスを追加または変更し、次に必要に応じて DAO レイヤーインターフェイスを追加または変更します。に対応します。最終的には実装を追加または変更する必要がありますが、実際に変更したいのは単なる SQL ステートメントであることがよくあります。

この一連の作業が面倒です。ポータルサイトは基本的に情報を表示し、そのビジネスロジックは基本的にSQL文に反映されます。考えてみてください、Web サイトに何が表示されているか、それをどのように並べ替えるか、どのように集計するか、これらはすべて対応する SQL ステートメントに対応しているのではないでしょうか?基本的な追加、削除、変更として DAO 層を記述し、その後、本来 SQL ステートメントに対応するビジネスロジックを実装するためにサービス層で大騒ぎする必要があるとしたら、一体何の意味があるのでしょうか?純粋にレイヤリングのためのレイヤリングですか？オブジェクト指向のためのオブジェクト指向?インターフェースが山積みになると、作業負荷が無駄に増加することは言うまでもありません。もちろん、プログラミング的思考におけるインターフェイスの重要性を否定するつもりはありませんが、従来の JAVA WEB プログラミングにおける一連のインターフェイスは本当に合理的なアプリケーションなのでしょうか?多くの場合はそうではないと思います。その後、PHP を使用してプロジェクト内の関数の大部分を書き直しました。これには、階層化やインターフェイスを使用せずに、わずか数日しかかかりませんでした。これによる作業効率の向上は本当に嬉しいですね！

2 番目: JAVA WEB プロジェクトのリリースでは通常、サービスの再起動が必要となり、WEB 操作が中断されます。 ホットデプロイメントが最終的にどのレベルに到達できるかはわかりませんが、ファイルがいつでも変更でき、いつでも有効になる PHP とは異なると思います。サービスを中断しないように、通常はクラスターを形成し、順番にリリースすることを選択します。これによって依然として問題が発生する可能性がありますが、アプリケーションを中断するよりははるかに優れています。ただし、クラスタリングすると公開時に問題が発生するため、クラスタ自体が本当に必要なものではない可能性があります。

それに伴う小さな問題もいくつかあります。たとえば、プロジェクトに多数のファイルを保存するフォルダーが含まれている場合、公開するときにそれらに特別に対処する必要があり、非常に不快です。ソフトリンクを作成したとしても、公開する際には必然的に余分な作業が必要になります。もちろん、これらの問題にはもっと良い解決策があると信じており、個人的にはまだ模索中です。

上記の問題に直面して、私はついにオブジェクト指向に固執するのをやめました。プロジェクトを PHP 以前および Java 以降の形式に変更しました。 PHP はフロントエンドとしてははるかに柔軟であるようで、リビジョン全体では PHP のロジック部分にはあまり時間がかからず、すべての時間を Java バックエンドが安定性と効率性を確保するために費やされました。簡単に安全に設計できます。ここから、私はついに「あまり面と向かってしないでください」という感嘆の声を発しました。他人の考えに従うことは、カルトに参加することと何ら変わりません。

JAVA バックエンド部分については、プラグインのホットロードと削除ができるプラグインベースの CMS バックエンドシステムをまだ検討中です。ああ、上記の理由から、棒で人を殴り殺すことはできません。

しかし、何はともあれ、著者の説明を読んだ後は、PHP と Java の組み合わせを試してみるとよいでしょう。オブジェクト指向を放棄することでどのようなメリットがもたらされるかを見てみましょう。