PHP プログラミング手法を再考する (パート 2)

2 日間先延ばしにしてきましたが、今夜ようやく次の章を書く時間ができました。しかし、いざパソコンに向かうと、どこから始めればよいのかわかりません。おそらく、ZEND FRAMEWORK に従ってください。もちろん、この記事はオブジェクト指向プログラミングの理解を説明するための例として zend フレームワークを使用しており、zend フレームワークの入門書ではありません。チュートリアルですが、オブジェクト指向についての私の理解。

02 1. 統合されたエントリーファイル

03 多くの人にとって、PHP はまだ「完全な」オブジェクト指向とはみなされていません。その理由は、オブジェクト指向とは、すべてのプログラムをオブジェクト化する必要があることを意味するはずであり、PHP は依然としてオブジェクト指向であると考えているからです。エントリーファイル。しかし、この種の学術的な議論は、実際には私たちとは何の関係もありません。完全にオブジェクト指向のアプリケーションであるため、index.php を除くすべてのプログラムはクラスの形式で記述する必要があることだけを知っておく必要があります。

04 zend フレームワークでは、リライト技術が使用されています。リライトは、疑似静的関数を使用して検索エンジンに登録されるだけでなく、セキュリティ リスクを回避するためにインデックスが作成された PHP ファイルの直接実行を禁止します。 joomla では、プロセス指向のプロジェクトであっても、discuz と phpwind の両方でリライト オプションが提供されていますが、多くの zf 初心者にとっては、リライトを使用する必要はありません。リンクの URL アドレスが異なるだけです。これについて言及している情報がないのは奇妙なことですが、実際、IIS および PHP をサポートするほとんどの仮想ホスト上で、書き換えの問題を心配することなく zend フレームワークを使用できます。

05 もちろん、私は個人的にリライト テクノロジーを強く支持します。私にとって、このテクノロジーには少なくとも 3 つの利点があります。1. 疑似静的手法を使用して検索エンジンのインデックス作成を強化します。2. 重要なファイルや危険なファイルが実行されたりダウンロードされたりするのを防ぎます。 ; 3. PHP を使用して画像ファイルを生成する場合、URL アドレスと実際の画像アドレスの形式はまったく同じです。

06 したがって、優れたオブジェクト指向プログラムは、エントリ ファイルを統合し、書き換え機能を使用して、他の非標準 PHP ファイルの使用を制限する必要があります。

07 2. MVC パターン

08 MVC は非常に古典的なプログラミング手法です。純粋に実行効率を追求するなら、プログラムページごとに1ファイルが最も効率的であることは、この記事の前回の記事でも述べました。ただし、人手では限界があるため、ファイルを細分化し、一定のルールに従って分類する必要があります。 PHP を長くやっている人なら、あらゆる種類の切り取りやファイル分類の手法を見たことがあるはずですが、その中で唯一パターンに昇華され、主流に受け入れられているのが MVC です。

09 プログラムとページが分離されている、つまりビューが独立していることが一般的に受け入れられているとしても、コントローラーとモデルを分離すべきかどうかについては、多くの人が依然として異なる意見を持っています。最初は、小規模なプロジェクトにはそこまでこだわる必要はないのではないかと考えていましたが、すぐにモデルの利点を発見しました。モデルは、プロセス指向のプロジェクトにおける関数ライブラリとほぼ同じ機能を持っています。関数ライブラリの利点は、関数を常に関数に分割する必要があると述べました。 , MODELはこれらの機能を統一的に分類したものに過ぎません。モデルと関数ライブラリの主な違いは、通常、各モデルにメソッドが多すぎないように、データ テーブルごとにモデルを構築することと、メソッドの名前を統一できることです。たとえば、関数ライブラリでは、記事の削除は delArticle()、画像の削除は delPicture()、ユーザーの削除は delUser() という名前になります。モデルごとに分けたら、それらをすべて del と呼ぶほうがずっときれいではないでしょうか。 ()?

10 したがって、プロジェクトの規模に関係なく、データベースが使用される限り、MODEL を使用する価値は常にあります。

11 議論する価値のある問題は、理論的には、モデルはデータ処理のみを担当し、私の以前のいくつかのプロジェクトでは、出力は zend フレームワークのビュー アシスタントにも配置されていたということです。しかし、最近、モデル内でリストとディレクトリ ツリーを直接生成する方法を確立したばかりです。ビュー アシスタントと比較して、多少の時間の節約になり、欠点は見つかっていないので、問題がなくなるまで続けます。モデル内の少量の出力: 文字列を生成し、それをコントローラー内の関連する呼び出しコマンドに返します。今考えると私の理解が間違っていたのかもしれません。おそらく、情報に記載されている MODEL は出力を担当せず、ページの直接表示とエコーなしの文字列の生成のみを必要とするため、そもそも許可されているのかもしれません。

12 3. phpunit テストフレームワーク

13 プロセス指向プログラミングでは、多くの人が必要に応じて関数を作成し、関数を呼び出す必要がある場所をテストするためにその関数を直接呼び出します。おそらく多くの人は、私と同じように、ある日突然、さまざまな外部要因による感染を許容できないことに気づき、これらのテストを実行するために新しい test.php を作成しました。その後、テストの数が徐々に増加するにつれて、test.php が変更されました。これは phpunit のプロトタイプです。プログラミング プロセス全体でテストに多くの時間がかかりますが、phpunit はこれらのテストを保存し、将来クラスやメソッドを変更するときにテスト時間を大幅に節約します。

14 4. クラスの抽象化と継承

15 私のコードでは継承が常に発生していますが、抽象化はほとんどありません。抽象化とインターフェイスには、プログラムを作成するための必須の定義要件があるため、協力者が少ないプログラマにとっては、あまり意味がないようです。しかし、プログラミング プロセスの自由さと緩さこそが、私たちや次のプログラマーが後で苦い結果を味わうことになることが多いのです。冒頭の章で、この投稿を書くことは私のこれまでの経験を振り返るプロセスであると述べました。つまり、ここで言いたいのは、以前に書いたコードには抽象化とインターフェイスがほとんどなかったということです。この点を補って、プロパティとメソッドの名前を統一します。

16 5. デザインパターン

17 これまでに、合計 23 のデザインパターンがまとめられていますが、その中で私はさらに登録モード、ファクトリーモード、シングルトンモードを使用しました。設計パターンは、以前のオブジェクト指向プログラミング手法の要約です。幸いなことに、zend フレームワークを使用してプログラミングする場合、多くの場合、その技術的な詳細をあまり知らなくても、設計パターンを直接使用できます。たとえば、登録クラス zend_register は登録モードとして使用されます。やzend_formではデコレーションモードが多用されており、リフレクションAPIなどの技術も適度に利用されています。もちろん、逆に、Zend フレームワークを学ぶことの難しさも増しています。テクノロジーを学ぶとき、それが何なのかを知るだけでは満足できず、その理由を知りたいと思うこともよくあります。また、これらのモードは明らかにマニュアルでカバーされていません。フレームワーク 習得が難しい理由は、デザインパターンなどの関連知識に対する深い理解が不足していることが大きく関係しています。

18 6. フレームワーク

19 多くの人は、zend フレームワークに触れるよりも、小規模で軽量なフレームワークを学習したいと考えています。実際、私自身も zend フレームワークの学習と適用に多くの苦労をし、多くの時間を無駄にしました。最後に、フレームワークによって私たちの元々のプログラミングの考え方が変わってしまったことに気づきました。習慣に固執してフレームワークを自分たちに合わせて変更するのではなく、マニュアルや入門ガイドに記載されているとおりにフレームワークを使用する必要があります。そうしないと、半分になってしまいます。半分の努力で結果が得られますが、得られるものよりも失うもののほうが多くなります。たとえば、私は最近次の機能を持つ Web サイトを作成しました。

20 1. フォーラムの投稿エリアにすべての記事のカテゴリリストと記事内容を表示します。

21 2. 送信されたすべての記事のリストを表示します。著者の友人による ;

22 3. Google サイトマップを自動的に生成します。

23 機能は確かに少ないですが、デザインページも含めて、zend フレームワークに基づいたこの Web サイトを完成させるのにわずか 2 日かかりました (丸 2 日ではありませんでした)。したがって、zend フレームワークは重量級のフレームワークとして知られていますが、小規模なプロジェクトの開発には確かに適しています。 zend フレームワークが大きすぎると思われる場合は、それほど多くの関数ライブラリを使用する必要はなく、習得したものだけを使用してください。 zend フレームワークの問題は、機能が多すぎて 1 つのプロジェクトですべてをマスターするのは不可能であることです。そのため、段階的に実行することを忘れないでください。

24 もちろん、実際にはフレームワークを全く使わずにMVCメソッドを本体としてオブジェクト指向のプログラムを書くこともできるので、理解できないのはそれらの軽量フレームワークの存在意義です。フレームワークが MVC パターンの単なるアーキテクトである場合、smarty に関する混乱と同様に、なぜ自分たちでそれを作成しないのでしょうか?

25 たとえば、次のように書くことができます:

26 Index.php

27

28 view plaincopy to Clipboardprint?

29

30 $controller=$ _GET['controller'];

31 require_once 'controller/'.$controller.'.php';

35

36 control.php

37

38 クリップボードプリントにコピーしますか？

39

40 require_once 'some_model.php';      

41 $model=new Some_Model();      

42 $string=$model->getString;      

43 require_once 'templates/templte.phtml';     

44

45 require_once 'some_model.php';    

46 $model=new Some_Model();    

47 $string=$model->getString;    

48 require_once 'templates/templte.phtml';    

49

50 some_model.php

51 クリップボードプリントへのプレーンコピーを表示しますか?    

52

53 class Some_Model extends PDO{

54 public function getString(){

55 $string='こんにちは、世界!';      

56 $string を返します。      

57 }

58 }

59

60 class Some_Model extends PDO{

61 public function getString(){

62 $string='hello world!';    

63 $string を返します。    

64 }

65 }

66

67 template.phtml

68

69 クリップボードプリントにプレーンコピーして表示しますか？    

70       

71 ......

72       

73       

74       

75      

76    

77 ......

78    

79    

80    

81    

82

83

84 この样、MVCモードの面向对象程序成功创建了吧？ PHP高级程序设计：モード、 「フレームワークとテスト」では、ここに独自のフレームワークの例が示されていますが、これらのフレームワークは、存在する価値がはるかに優れていると感じています。库事实上是一标標準制定，回忆一下我们到现在，精竟换何类库？あるアプリケーションでは、機能要求が異なるため、作成者が未登録のダウンロード アクセスを更新したり、自己書き込みしたりするなどの理由で、再書き込みを停止し、別の種類に置き換えることがよくあります。 zend フレームワーク フレームワークを採用し、そのクラスのフレームワークのみを使用して、その分野に限らず迅速に淘汰され、大企業から出品され、すべての能力を発揮します。

86 したがって、オブジェクトに向かうプログラムは、その後も Zend フレームワークに基づいて記述されます。 、请

以上は PHP プログラム方式の再考(下)の内容であり、より多くの関連内容は PHP中文网 (m.sbmmt.com) に注目してください！