仕様3_PHPチュートリアル-PHPチュートリアル-php.cn

ディレクトリ文書すべてのディレクトリには、以下を含む README 文書が必要です。ディレクトリの機能とその内容各ファイルのオンライン説明 (リンク付き) 通常、各説明ではファイル名の一部の属性も抽出されます。関連リソースへの接続方法を説明するためのセットアップと使用方法の説明が含まれています。ソースファイルのインデックスオンラインドキュメント紙のドキュメント設計ドキュメント読者に役立つその他の事項元のエンジニアリングスタッフ全員が 6 か月以内に退職し、入社したときのことを考慮してください。孤独で怯えている探検家は、プロジェクト全体のソースコードディレクトリツリーを使用し、ドキュメントやソースファイルのヘッダーの説明などをマップとして読み、プロジェクト全体を横断できる必要があります。-------------------------------------------------- ---------------------------- デザイン表記法とプロセスを使用するプログラマーは、コーディング、デザイン、ソフトウェアプロセス全般。これはプロジェクトの成功にとって重要です。どのプロジェクトにも、さまざまなスキル、知識、経験を持つ人々が集まります。たとえプロジェクトの参加者全員が天才だったとしても、プロジェクトを結び付ける共通の言語やプロセスがないため、人々は際限なくすれ違い続けるため、失敗することはあります。大規模な戦い、燃え尽き症候群、そしてほとんど進歩が得られないだけです。グループをトレーニングに参加させた場合、経験豊富な専門家が戻ってくるとは限りませんが、少なくともグループ全員が同じ認識を持つことになります。チーム。世の中には人気のある方法論がたくさんあります。重要なのは、リサーチを行い、方法を選択し、それについて従業員をトレーニングし、それを使用することです。このページの上部にあるさまざまな方法論へのリンクをご覧ください。設計を解明するための CRC (クラス責任カード) アプローチが役に立つかもしれません。他にも多くの人がそうしています。これは、チームの協力を促進し、属性を持つオブジェクトではなく、何かを実行するオブジェクトに焦点を当てる非公式なアプローチです。それについては、Nancy M. Wilkinson 著『Using CRC Cards』という本も出版されています。 -------------------------------------------------- ---------------------------- ユースケースの使用ユースケースは、複数のオブジェクトが関与するトランザクション全体の一般的な説明です。ユースケースは、組織などの一連のオブジェクトの動作を記述することもできます。したがって、ユースケースモデルはユースケースのコレクションを示し、通常はシステムと対話する 1 つ以上の外部アクターとともにアプリケーションシステム全体の動作を指定するために使用されます。個々のユースケースには名前が付いている場合があります (ただし、通常は単純な名前ではありません)。その意味は、多くの場合、トランザクションを構成する外部アクターとオブジェクト間のイベントのシーケンスについての非公式のテキスト記述として書かれます。ユースケースには、その動作の一部として他のユースケースを含めることができます。要件のキャプチャユースケースでは、システムの要件を理解可能な形式でキャプチャしようとします。このアイデアは、一連のユースケースを実行することで、システムが本来行うべきことを実行していることを検証できるというものです。システムが何を達成する必要があるかを説明するために、必要なだけ多くのユースケースを用意します。プロセス構築しようとしているシステムを理解することから始めます。さまざまな利用者全員がシステムをどのように使用するかを説明する一連のユースケースを作成します。システムのクラスとオブジェクトモデルを作成します。すべてのユースケースを実行して、モデルがすべてのケースを処理できることを確認します。必要に応じてモデルを更新し、新しいユースケースを作成します。 -------------------------------------------------- ---------------------------- オープン/クローズの原則オープン/クローズの原則では、クラスはオープンかつクローズでなければならないと規定されています。クラスが拡張できることを意味します。「closed」は、クラスが拡張以外の変更に対して閉じられていることを意味します。コードレビュー、単体テスト、その他の認定手順を経てクラスの使用が承認されたら、クラスをあまり変更せず、拡張するだけでよいという考え方です。オープン/クローズの原則は安定のためのピッチです。システムは、すでに動作しているコードを変更するのではなく、新しいコードを追加することによって拡張されます。プログラマーは、古いコードが機能するからといって、変更することに抵抗を感じることがよくあります。この原則は、あなたの懸念を学術的に正当化するものを提供するだけです :-) 実際には、オープン/クローズの原則は、単に私たちの古くからの友人である抽象化とポリモーフィズムをうまく利用することを意味します。共通のプロセスやアイデアを取り出すための抽象化。派生クラスが従う必要があるインターフェイスを作成するための継承。 -------------------------------------------------- ---------------------------- 契約による設計契約による設計の考え方は、LSP と強く関連しています。契約は、相手方に何を期待するかを正式に表明したものです。この場合、コントラクトはコード間の部分にあります。オブジェクトやメソッドは、それが X を行うと述べており、それを信じる必要があります。たとえば、オブジェクトの体積を尋ねると、それが得られるはずです。また、体積は物の検証可能な属性であるため、一連のチェックを実行して、体積が正しいこと、つまり契約を満たしていることを検証できます。エッフェルのような言語では、実際には言語の一部である事前条件文と事後条件文によって契約が強制されます。他の言語では、少し信仰が必要です。言語ベースの検証メカニズムと組み合わせた契約による設計は、非常に強力なアイデアです。これにより、プログラミングが仕様の部品を組み立てるようになります。 -------------------------------------------------- ---------------------------- その他の部分には、さまざまな行われたことと行われていないことが含まれます。浮遊量を必要とする数値を使用して、循環カウンタを自分で起動する必要がなくなります。浮動小数点数をテストするときは常にを使用し、 = や => を使用しないでください。自動プログラム整形機能を使用しないでください。優れたプログラムスタイルの恩恵を受けるのは主にプログラマー自身であり、特にコーディングとアルゴリズム設計を始めたばかりのプログラマーは、構文に基づいてプログラムを修正することしかできないため、使用できません。空白とインデントには十分な注意が必要です。細部に注意を払う普通のプログラマは、明確で直観的なスタイルを使用して関数やファイルを完成させることができます (言い換えると、一部の直観的なスタイルは、プログラムの自動整形機能が読み取ることができる知恵ではなく、意図を規定したものです)。ずさんなプログラマーは、プログラムの可読性を高めるために自動プログラム美化ツールに頼るのではなく、注意深いプログラマーから学ぶべきです。元のビューティファイアは、ソースコードを分析する必要があるプログラムでした。複雑なビューティファイアにはメリットがありません。ビューティファイアは、機械生成形式でコードを生成するために使用するのが最適でした。論理式内の 2 番目の = を誤って省略すると、次のようなエラーが発生し、混乱を招きます。 if ($abool= $bbool) { ... } プログラマは本当にここに値を代入したかったのでしょうか。通常はそうなりますが、通常はそうではありません。このような混乱を避けるにはどうすればよいでしょうか?解決策は、これを行わず、明示的および暗黙的な判定テストを使用することです。推奨される方法は、テスト前に代入を行うことです。 $abool= $bbool; if ($abool) { ... } ----- --- ----------------------------------------------- --- ----------------------- if (0) を使用して外部コードブロックをコメント化する場合によっては、テストコードの大部分をコメント化する必要がある場合があります。最も簡単な方法は次のとおりです。 use if (0) block: function example() { 見栄えの良いコード if (0) { たくさんのコード } さらに多くのコード } コメント内にコメントを含めることはできないため、/**/ は使用できませんが、コメントは大きな範囲内に含めることができます。プログラムのセクションですね。 -------------------------------------------------- ----------------------------- さまざまなアクセサスタイルアクセサメソッドがオブジェクトの物理属性または論理属性へのアクセスを提供するのはなぜですか?依存関係を解消するために属性への直接アクセスを禁止しているのは、属性に直接アクセスするとオブジェクトの実装の詳細が公開されるからです。オブジェクトが物理的以外の方法で属性を提供することにした場合はどうなるかを自問してください。属性のデータベース検索を行う必要がある場合はどうなるでしょうか? 上記の変更されたコードのいずれかが壊れる場合はどうなりますか?物理属性へのアクセスは、そのような属性を保証するものではありません。 Get/Set class X { return $this->mAge } function SetAge($age) { $mAge= $age; } var $mAge; } 1 つのメソッド名 class X { function Age() { return $mAge } function Age($age) { $mAge= $age; } $ mAge; } Get/Set に似ていますが、このアプローチは、オブジェクトとしての属性を使用しない場合に使用します。 } 関数 Name() { return mName } 関数 rN

;