PHPは成熟しました

PHP は成熟しつつあるため、すぐに使えるすぐに使えるスクリプターが、UML を理解しているオブジェクト指向開発者と「同じ考え方」をする時代が来ています。

PHP ほど急速に人気を博したプログラミング言語はほとんどありません。現在広く知られている、DIY (DIY) スクリプト言語が IT 業界を変革しているという話は、成功が必ずしも体系的な計画や市場調査から得られるわけではないことを示しています。しかし、今の本当の問題は、この成功が巨大な IT 業界にどのように受け入れられるかです。 Oracle および他の大手企業数社が PHP に注目しており、この言語が成熟しているという事実が示しています。

これまでの成功は「現れた」だけでした。まるで天才児のように PHP の周りに集まる愛好家が増えています。しかし、その子供がひげを生やし、大人と対等に話し始めた今、初期の支持者たちは変化に適応できるだろうか？

PHP は、ほとんどの主要なオープンソース プロジェクトと同様、主流のテクノロジーになる過程における基本的な現象です。 PHP は、その評判を与えてくれた人々の期待を裏切ることになるでしょうか?巨大IT業界の期待に応えられるだろうか？

2 つのプログラミング文化の物語

PHP の成功は、さまざまな背景を持つ人々の注目を集めています。初期の Rasmus 支持者たちは (オープンソース界ではあまり見られない、やや救世主的な口調であることをご容赦いただければ)、高速ですぐに使えるスクリプト手法に慣れており、今では UML を理解している人々と争わなければなりませんでした。 PHP を他の最新の開発ツールと同等に保つことを決意している、OO 指向のプログラミング開発者。両者は Web 開発に精通しており、強力な文化を持っています。どちらの側も無視するのは賢明ではありません。

初期の PHP タイプは Web 開発について何を知っていましたか? 何が得意で、何が苦手でしたか?デザインについてよく知っています。そのスタイルは時々疑わしい場合がありますが、より一般的なリッチ インターネット アプリケーション (RIA) テクノロジは言うまでもなく、HTML および CSS 機能を備えていることがわかります。常に若いですが、PHP フォーラムに頻繁に登場します。 「オブジェクト指向」という用語には否定的な意味合いがあるかもしれません。コードは簡潔で、保守性よりもパフォーマンスに重点を置いています。

UML 型は、変数の型指定が緩く、HTML コードに ステートメントが埋め込まれているため、あまり魅力的ではありません。アプリケーションのアーキテクチャ、クラスレベルのコードの再利用、チームワーク、ソース コードの管理について検討します。ある程度複雑な Web サイトであっても、何よりもまずアプリケーションであり、アプリケーションの設計が不十分だと遅延、クライアントの迷惑、さらには職の喪失につながる可能性があることを知っています。

一見すると、後者のほうが、マーケティング戦略や経済的要因によって Web 開発がますます推進される、ますます要求が厳しくなる環境により適しているように見えます。しかし、前者を絶滅危惧種と考えるべきでしょうか？もしかしたらこのままではいけないのかもしれない。 Web がデスクトップ システムとはまったく異なるメディアであることを受け入れるなら、メインフレーム (3270 を覚えている人はいるでしょうか?) は言うまでもなく、メインフレーム環境での主要な開発方法論を生み出したものであるという結論に達するかもしれません。そして、この成功したが比較的厄介なアプローチから学べる効果的なこと。

発生する前に克服すべき実際の問題を確認し、実際の作業方法をいくつか確認してみましょう。

文化的なギャップを埋める

現在、PHP5 はオブジェクト指向テクノロジーを PHP の世界に導入しようとしています。 Zend エンジンの修正 (ZE2) により、オブジェクトが言語のコアに組み込まれています。新しい言語構造がオブジェクト プログラミング スタイルを奨励しているだけでなく、言語の実装も他のオブジェクト指向環境に適応されています。たとえば、デフォルトではオブジェクトを前後にコピーするのではなく、参照によって処理されます。新しいキーワード (final や static など) が導入されていますが、これらはオブジェクトの概念にのみ関連しており、Java スタイルを維持するものであり、他の機能 (委任など) はオブジェクト設計パターンの使用を促進します。 (数か月以内にみんなが「オリジナルの PHP4」について話しているのを聞くことを期待してください。) この重大な変化は、現在主流のプログラミング モデルへの容赦ない革命的な移行によってもたらされます。オブジェクト アプローチは、好むと好まざるにかかわらず、Web アプリケーションであるかどうかに関係なく、複雑なアプリケーションを配信するのに最も効果的であることが証明されているため、今後も定着し続けます。したがって、デザインについて考える人々と建築を理解する人々が互いの長所を学ぶことができるように、2 つの文化を調和させる想像力豊かな方法を見つける以外に選択肢はありません。

これを行うには、言語を明確な境界内に収めながら言語の多用途性を得るメソッドを開発 (または他のプラットフォームから翻訳) する必要があります。このようにして、プログラミングの創造性の「島」が堅牢なアーキテクチャ内に存在することができます。

明らかな事実の 1 つは、PHP CMS またはアプリケーション フレームワークの数が爆発的に増加しているにもかかわらず、それらについてのコンセンサスが存在していないということです。よく寄せられる不満は、プロジェクトが何であっても、既存のシステムでは仕事がうまくいかないということです。人々は多くの場合、いくつかのシステムの評価から始めて、最終的に独自のフレームワークを最初から開発することになります。何故ですか？

GUI デザインの問題がオペレーティング システムによって完全に解決されたように見えるデスクトップ システムとは対照的に、Web は独自のビジュアル デザインが重要な役割を果たすプラットフォームです。 Web サイトには企業のイメージや個性が掲載されており、収益にますます影響を与える可能性があります。視覚的な創造性はブランディングと密接に関係しているため、それを促進する必要があります。

同時に、ユーザー エクスペリエンスを可能な限り向上させるために、アプリケーションに柔軟なロジックを組み込むことができなければなりません。その際、ユーザーは Web 上での方が実際よりも洗練されているということを念頭に置いてください。デスクトップシステム。

設計者がシステムプログラマーの設計に常にイライラしている場合は問題ですが、開発者がアプリケーション コードを不完全なポータル フレームワークに強制的に組み込む必要がある場合も同様に問題です。最も一般的な結果は、アプリケーションの複雑さを管理可能なレベルに制限するために多くの使いやすさを犠牲にし、見た目がやや鈍くなり、満足のいく妥協ができないことです。 (この現象は PHP アプリケーションに限定されたものではありません。)

これらの制限を完全に克服するには、デザイナーとオブジェクト指向開発者は、お互いの作業を妨げることなく共同作業する方法を見つける必要があります。最善のアプローチは、他のチームがどのように機能するかを理解することから始めることかもしれません。

テクノロジーから産業へ

現時点ではコラボレーションの問題について考えず、実際の運用を観察してみましょう。 PHP の歴史的な順序で始めましょう。まず、「拡張 HTML」ユーザーのストアにアクセスします。

取引ツールは「純粋な HTML」ユーザーのツールと非常に似ています。いくつかの HTML エディターには、さまざまなレベルの快適な機能とプロジェクト管理機能があり、ある程度は PHP、ASP、JavaScript と統合されています。それほど重要ではないツール。

コードを詳しく見てみましょう。まず最初に気づくのは、これらのさまざまな種類のツールを使用して作成された Web サイトが非常に美しいということです。ここではスキルだけではなく、才能についても話しています。抽象的なプログラミング要素の制約から解放された Web デザイナーは、実際の店舗で抜け目のない装飾者が作成するものと同様に、ポジティブで微妙な感情的効果を試すことで、Web サイトの顧客を安心させる視覚環境を作成します。

訓練を受けたオブジェクト指向プログラマの観点からこのコードを見ると、突然事態が大きく狂ってしまいます。このコードは、実際のコードのように見えます。1 回限りの、忘れてしまえばよいジョブであり、将来の開発や簡単なメンテナンスのための備えはありません。確かに、よくあることです。

それで、これの何が問題なのでしょうか?後で問題が発生して、サイトの一部または全体を放棄し、最初から再構築することになるのでしょうか？たぶんそうではありません。結局のところ、実際の店舗の装飾は定期的に取り壊されて再構築されることがよくあります。したがって、これらのショーケース Web サイトでは、カウボーイ スタイルの PHP プログラミングで十分です。この言語には、訪問者の注意を引くための視覚効果を実現するためのテクニックが豊富に含まれています。これは明らかにオブジェクト メソッドとは関係ありません。

アプリケーション ロジックが必要になると、この観点は大きく変わります。サイトの頻繁な訪問者に関する少量のマーケティング情報を収集するには、いくつかのフォームが必要ですか?この情報に関連性を持たせたい場合は、確認コードを追加することをお勧めします。これを行う場合は、悪意のあるスクリプトまたは SQL 命令による侵入攻撃を確実にフィルタリングできるようにする必要があります。ところで、あなたは OTN の記事を読んでいるので、データベース (DB) の問題に精通している必要があります。収集する情報はデータベース テーブルに保存され、PHP コード内の SELECT ステートメントはこのデータベース構造を反映します。今後、この Web サイトはすでにビジネス インフラストラクチャに固定され、本格的なアプリケーションになります。

ここでは、ハードコーディングされたリンク、危険な型変換、セキュリティ ホールをすべて脇に置いて、PHP オブジェクト指向アプリケーションの最新の組み立てラインを見てみましょう。私たちアーティスト志向の Web デザイナーにとって、この種の場所は馴染みがなく、おそらく不親切ですらあるかもしれません。ここではテクニックにはあまり重点が置かれていません。 Web 開発は産業化されました。ここで受け入れられるには、クラス、継承、データ抽象化、および多数のコード カプセル化ツールに精通している必要があります。

チームワークにはルールが必要です。プログラミング規則に従う必要があり、ソース ファイルはバージョン管理とソース コード管理に提出する必要があります。ファイルは厳密なモジュール階層に従って編成されます。危険なコーディング手法、特に巧妙なコーディング手法は排除されます。コードは読みやすいだけでなく、適切なコメントが付けられている必要があります。

これは面倒かもしれませんが、機能します。現在、私たちは Web アプリケーションを作成しています。イントラネット、ビジネス Web サイト、電子市場、設計に欠陥があるとビジネスが停止する可能性があるあらゆる種類のアプリケーションです。要するに、私たちは複雑さを克服しているのです。

PHP オブジェクト指向の組立ライン管理者は、言語が好きだから PHP を選択したのではありません。彼らがそうするのは、他の独自言語と同じくらい効率的に仕事を遂行できるだけでなく、無料で何の制約も付かないからです。

どこへ行くの?

それでは、C と Java の訓練を受けた人が提供する業界グレードのメソッドをどのように活用して、多用途言語の早期採用者の専門知識を補完できるのでしょうか?

PHP5 は多くの習慣を揺るがすことになるため、この質問は時期尚早かもしれません。ある程度のオブジェクト指向アプローチの採用を余儀なくされる人もいるでしょうが、最終的にはオブジェクト指向についてすべてを学び、オブジェクト指向の信者になる人もいます。特定のニッチ市場は過去と同様に機能し、今後も繁栄し続ける可能性があります。

実践してみましょう

次に、簡単な習慣を形成する方法を理解し、簡単で効果的な解決策を見つける方法を理解するために、基本的な技術レベルに飛び込んでみましょう。これから起こる変化。非常に単純な規則の多くは、プログラミングを容易にし、アプリケーションを拡張できるようにするのに役立ちます。

命名規則 (C プログラマーの習慣) が最も簡単な方法です。すでにコード ベース (PEAR など) を頻繁に使用している場合は、その規約を独自のものとして採用することをお勧めします。それ以外の場合は、独自の内部ルールを作成する必要があります。簡略化されたハンガリー語アノテーション (ハンガリーの発明者 Charles Symonyi にちなんで命名) は、ルーズ タイプが許す限り広く使用できます。クラスメンバーの前にアンダースコアを使用することもできます。もう 1 つの便利な習慣は、クラスの外部から呼び出すことを意図していないメソッド (クラスに属する関数) に特別なプレフィックス (impl_ など) を追加することです。

どのような命名規則を使用する場合でも、コードはできる限り明確にしてください。したがって、訓練を受けた人は、肖像画の汚れのように、見た目が間違っているという理由だけで、PHP でいっぱいの画面でプログラミング エラーを見つける可能性があります。

命名規則のもう 1 つの重要な側面は、名前の競合を回避し、コードを大規模に再利用できるようにすることです。経験上、プログラマはプログラミング オブジェクトに名前を付ける際に必ずしも想像力が豊かであるとは限りません。世の中には多くの Page クラスが存在する可能性があり、2 つの Page クラスを再利用した結果、名前は同じだが目的がまったく異なることが判明するということも不可能ではありません。本当に不運だ。長期的には、名前を変更するとメンテナンス上の問題が発生します。この問題は最初から回避したほうがよいでしょう。 GUID の生成はやりすぎで見苦しく (例: _16B280C5_EE70_11D1_9066_00C04FD9189D_Page!)、PHP の精神に反します。

競合を防ぐ簡単な方法は、クラスのいくつかの異なる側面をその名前 (GalleryPage など) に関連付けることによって、内部クラスが一意になるようにすることです。これにより、スコープを制御する必要がなくなります。万が一クラスの競合が発生した場合は、Java の方法で、所有するドメイン名の予約バージョンをプレフィックス (com_mydomain_GalleryPage) に付けることができます。

コストがかからず、特定のアプリケーション スコープに対する予期せぬ変更が避けられない場合に作業を節約できるもう 1 つの習慣は、最も一般的に使用される基本的なステートメントを別のチャネルにカプセル化することです。たとえば、コードのデバッグを除き、アプリケーション全体に「応答」ステートメントは 1 つだけ存在し、それは何らかの関数 (または別のクラス メソッド) 内に存在する必要があります。新しい環境で出力の前処理やリダイレクトが必要な場合でも、大きなファイルの検索や編集というイライラする状況に直面することなく、必要な数行のコードをどこに配置すればよいかがわかります。

エラー処理は C ほど厳密である必要はありません。C では、ダングリング ポインタやバッファ オーバーフローが非常に破壊的になる可能性があります。データの整合性が損なわれていない場合は、寛大になって、一部の機能は完璧ではありませんが、もう一度試してみることができると訪問者に伝えてください。見落とされがちなヘルパーは、標準の set_error_handler() 関数です。これは、今回は基本イベントが、すべてのコードがこれらの基本イベントの処理専用に集中される場所にカプセル化される別の例です。発生するすべてのエラーのイベント ログを保存して、再発する問題を特定したい場合は、ここで行う必要があります。

低レベルプログラミングの話を終える前に、命を救うもう 1 つのトリックがあります。 PHP5 では、デフォルトでオブジェクト参照が割り当てられるか渡されます (参照はオブジェクトへのハンドルであり、オブジェクト自体やオブジェクトのコピーではありません)。 PHP4 を使用する必要がある限り、オブジェクトがどのように受け渡されるかについて細心の注意を払う必要があります。あなたを不安にさせるかもしれないいくつかの微妙な点があります。たとえば、次のステートメントにより $obj2 が $obj1 のコピーになりますが、これは驚くべきことではありません。

$obj2=$obj1;

特に指定がない限り、関数はコピーを使用し、コピーを返します。このケースを受け入れる必要があります。次の例では、追跡が難しいエラーが多数発生します。

class ObjectKeeper {
var $_obj; // オブジェクトは何でも
function & get_object() {
return $this- >_obj;
}
}
//リファレンスもしっかり返せます。ここでトラップが表示されます:
$keeper = new ObjectKeeper();
$obj1 = $keeper->get_object();
$obj1->modify();
$obj2 = $ keeper->get_object(); // 同じオブジェクトへの新しい参照を要求します
if ($obj2->is_modified()) {
echo 'OK' // これは表示されません
}

正しいステートメントは次のようになります:

$obj1=&$keeper->get_object() // "=" =" であることに注意してください。

=& を指定しないと、返された参照が指すオブジェクトのコピーが $obj1 に割り当てられ、正しいと思われる参照に対して何をしても、オブジェクトの元の状態には影響しません。つまり、更新内容は失われます。

テンプレートは、Web デザイナーとプログラマーの文化を調和させるのに大いに役立ちます。通常、レイアウトに含まれるすべてのもの (主に HTML コード) が含まれており、ページの生成時にテンプレート エンジンがすべての変数コンテンツを埋め込みます。ほとんどのテンプレート エンジンには、データ ソースの更新で必要な場合にのみリソースを大量に消費する処理が確実に行われるようにするキャッシュ メカニズムが含まれています。

次のステップ


フォーラム: PHP on Oracle

PHP ヒッチハイク ガイド

オープンソース開発者センター

Oracle PHP トラブルシューティング ガイド

PHP スクリプト : フリーホイーリング コードの人気が高まっています

Oracle PHP 入門

Linux への Oracle、PHP、および Apache のインストール

テンプレート エンジンを使用すると、一方の側でレイアウトとグラフィックスを、もう一方の側でビジネス ロジックをかなりの程度分離できます。おそらく最も人気のあるテンプレート エンジンは Smarty で、多くのオープン ソース CMS およびフレームワーク プロジェクトにも統合されています。

最後に、ロジックが基本的な検索と置換を超える場合、テンプレート エンジンはプログラミングの方言を提供する傾向があることに注意することが重要です。将来のアプローチは XSLT テクノロジーに依存する可能性が高く、その結果、PHP5 の拡張 XML サポートは大きく変わるでしょう。

最後に、非常に重要な実践的な側面があります。それは、よく知られたライブラリからの一流のコードを再利用することです。 PEAR は現在標準の PHP ディストリビューションの一部であるため、私たちの調査は
PEAR
に限定されます。

現在、PEAR はおそらく真の標準 PHP ソフトウェア コンポーネントに近づいています。プロバイダーの厳格な選択と厳格な品質基準により、コンポーネントが商用グレードのコンポーネントと同等の品質であることが保証されます。バージョン管理規則により、アプリケーションに適切なコンポーネントのバージョンを正確に制御できます。 PEAR は、フォーム処理からデータベース抽象化レイヤー (PEAR::DB) までの豊富な機能セットを提供し、Web サービスや WebDAV サポートなどの高度な機能を備えています。
言うまでもなく、PEAR や同様の PHP コード ライブラリに慣れることで、何日にもわたる集中的な研究開発作業を節約できます。
PHP5 が登場します


PHP は、Linux や Apache と並んで最大のオープンソースのサクセスストーリーの 1 つとしての地位を確立しています。欠点はあるものの、IT の世界で確固たる地位を確立しており、多くのユーザー層が今でも愛用しています。

PHP5 では、データベースと対話するビジネス ロジック層で PHP コードの受け入れが増えており、高負荷の Web アプリケーションの開発が容易になる可能性があります。同時に、柔軟なプログラミング手法では XML テクノロジーの使用が増え、Web デザイナーが開発者やソフトウェア デザイナーとスムーズに連携することが容易になります。 私たちは、非常に魅力的で使いやすい新世代の PHP ベースの Web アプリケーションが登場することを楽しみにしています。