これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 ----- Arthur J.Riel
(1) すべてのデータは、それが配置されているクラス内に隠蔽されるべきです。
(2) クラスのユーザーはクラスのパブリックインターフェースに依存しなければなりませんが、クラスはユーザーに依存することはできません。
(3) クラスプロトコル内のメッセージを最小限に抑えます。
(4) すべてのクラスが理解できる最も基本的なパブリックインターフェース[例えば、コピー操作(深いコピーと浅いコピー)、等価性の判断、正しい出力内容、ASCII記述からの解析など]を実装します。
(5) 実装の詳細（共有コードを配置するプライベート関数など）をクラスのパブリックインターフェイスに入れないでください。
クラスの 2 つのメソッドに共通のコードがある場合、これらの共通のコードを防ぐプライベート関数を作成できます。
(6) ユーザーが使用できないものや興味のないものでクラスのパブリックインターフェイスを妨害しないでください。
(7) クラス間の結合はゼロ、または派生結合関係のみである必要があります。つまり、あるクラスは別のクラスとまったく関係がないか、別のクラスのパブリック インターフェイスでの操作のみを使用するかのどちらかです。
(8) クラスは 1 つの主要な抽象概念のみを表す必要があります。
パッケージ内のすべてのクラスは、同じ種類のプロパティの変更に対して共同でクローズされる必要があります。変更がパッケージに影響を与える場合、そのパッケージ内のすべてのクラスに影響しますが、他のパッケージには影響しません
(9) 関連するデータと動作を一元管理します。
デザイナーは、get などの操作を通じて他のオブジェクトからデータを取得するオブジェクトに注意を払う必要があります。このタイプの動作は、この経験原則に違反していることを意味します。
(10)関係のない情報を別のクラスに入れる（つまり、お互いにコミュニケーションをとらない行為）。
安定性への依存性
(11) モデル化する抽象概念が、オブジェクトが果たす役割だけではなく、クラスであることを確認してください。
(12) システム機能を水平方向にできるだけ均一に分散する、つまり、設計に従って、最上位クラスは作業を均一に共有する必要があります。
(13) システム内に全能のクラス/オブジェクトを作成しないでください。 Driver、Manager、System、および Susystem を名前に含むクラスには特に注意してください。
インターフェースを実装するのではなく、インターフェースを計画する。
(14) パブリックインターフェースに多数のアクセスメソッドを定義するクラスには注意してください。アクセス方法が多数あるということは、関連するデータと動作が集中的に保存されていないことを意味します。
(15) 相互の意思疎通が図れない行為が多すぎるクラスには注意してください。
この問題のもう 1 つの兆候は、アプリケーション内のクラスのパブリック インターフェイスに多数の get 関数と set 関数を作成することです。
(16) ユーザーインターフェースと対話するオブジェクト指向モデルで構成されるアプリケーションでは、モデルがインターフェースに依存するのではなく、インターフェースがモデルに依存する必要があります。
(17) 可能な限り現実世界に従ってモデル化する（システム機能分散の原則を遵守し、汎用クラスの原則を回避し、関連するデータと動作を集中的に配置するために、この原則に違反することがよくあります）。
(18) デザインから不要なクラスを削除します。
一般的には、このクラスをプロパティにダウングレードします。
(19) システム外のクラスを削除します。
システム外のクラスの特徴は、抽象的に言えば、システムドメインにメッセージを送信するだけで、システムドメイン内の他のクラスからのメッセージは受け付けないことです。
(20) オペレーションをクラスにしないでください。名前が動詞であるか動詞から派生したクラス、特に意味のあるアクションが 1 つだけあるクラスには質問してください。意味のある動作を、既存のクラスまたはまだ発見されていないクラスに移動する必要があるかどうかを検討してください。
(21) アプリケーションの分析モデルを作成する際に、プロキシクラスを導入することがよくあります。設計段階では、多くのエージェントが役に立たず、削除する必要があることがわかります。
(22)クラスの協力者の数は最小限にする。
クラスが使用する他のクラスの数はできるだけ少なくする必要があります。
(23) クラスとコラボレーター間で受け渡されるメッセージの数を最小限に抑えます。
(24) クラスとコラボレーター間のコラボレーションの量を最小限に抑える、つまり、クラスとコラボレーターの間で受け渡されるさまざまなメッセージの数を減らす。
(25) クラスのファンアウトを減らす、つまり、クラスで定義されたメッセージの数と送信されるメッセージの数の積を減らすようにしてください。
(26) クラスに別のクラスのオブジェクトが含まれている場合、それを含むクラスは、含まれているオブジェクトにメッセージを送信する必要があります。つまり、包含関係は常に使用関係を意味します。
(27) クラスで定義されたほとんどのメソッドは、ほとんどの場合、ほとんどのデータ メンバーを使用する必要があります。
(28) クラスに含まれるオブジェクトの数は、開発者の短期記憶の容量を超えてはなりません。この数は多くの場合 6 です。
クラスに 6 つを超えるデータ メンバーが含まれる場合、論理的に関連するデータ メンバーをグループに分割し、新しい包含クラスを使用してこのメンバーのグループを含めることができます。
(29) システム機能を狭く深い継承体系で垂直に分散させる。
(30) セマンティック制約を実装するときは、クラス定義に基づいて実装するのが最善です。これは多くの場合、クラスのオーバーフローにつながります。この場合、制約はクラスの動作に実装する必要があります。通常はコンストラクターに実装する必要がありますが、必ずしもそうである必要はありません。
(31) クラスのコンストラクターにセマンティック制約を実装する場合、コンストラクター ドメインで許可される最も深い包含レベルに制約テストを配置します。
(32) 制約が依存するセマンティック情報が頻繁に変更される場合は、それを一元化されたサードパーティのオブジェクトに置くのが最善です。
(33) 制約が依存する意味論的情報がめったに変更されない場合、制約に関与するさまざまなクラス間で分散するのが最適です。
(34) クラスはそれに何が含まれているかを知らなければなりませんが、誰がそれを含んでいるかを知ることはできません。
(35) リテラルスコープを共有する（つまり、同じクラスに含まれる）オブジェクトは、相互に使用関係を持ってはなりません。
(36) 継承は専門化階層をモデル化するためにのみ使用されるべきです。
(37) 派生クラスは基底クラスを知っている必要があり、基底クラスは派生クラスに関する情報を知っていてはなりません。
(38) 基本クラス内のすべてのデータはプライベートである必要があり、保護されたデータを使用しないでください。
クラスの設計者は、クラスのユーザーが必要としないものをパブリックインターフェイスに決して配置すべきではありません。
(39) 理論的には、継承階層は深くあるべきであり、深ければ深いほど良いです。
(40)実際には、継承階層の深さは平均的な人の短期記憶容量を超えてはなりません。広く受け入れられている深さの値は 6 です。
(41) すべての抽象クラスは基底クラスである必要があります。
(42) すべての基底クラスは抽象クラスである必要があります。
(43) データ、動作、インターフェースの共通点を継承階層の可能な限りハイエンドに配置します。
(44) 2つ以上のクラスが共通のデータを共有する(ただし、共通の動作はしない)場合、共通のデータをクラスに配置し、このデータを共有する各クラスにこのクラスを含める必要があります。
(45) 2 つ以上のクラスが共通のデータと動作 (つまり、メソッド) を持つ場合、これらのクラスのそれぞれは、これらのデータとメソッドを表す共通の基本クラスを継承する必要があります。
(46) 2つ以上のクラスが共通のインターフェース(メソッドではなくメッセージを参照)を共有する場合、多態的に使用する必要がある場合にのみ、共通の基本クラスから継承する必要があります。
(47) オブジェクトタイプの表示のケースバイケース分析は、一般的に間違っています。このような場合、ほとんどの場合、設計者はポリモーフィズムを使用する必要があります。
(48) 属性値の表示の状況分析は間違っていることが多い。クラスは継承階層に分離され、各属性値が派生クラスに変換される必要があります。
(49) 継承関係を通じてクラスの動的セマンティクスをモデル化しないでください。静的セマンティクス関係を使用して動的セマンティクスをモデル化しようとすると、実行時に型が切り替わります。
(50) クラスオブジェクトを派生クラスにしないでください。インスタンスが 1 つしかない派生クラスには注意してください。
(51) 実行時に新しいクラスを作成する必要があると考えたら、一歩下がって、オブジェクトを作成していることを認識してください。次に、これらのオブジェクトをクラスに一般化します。
(52) 派生クラスで空のメソッド (つまり、何もしないメソッド) を使用して基本クラスのメソッドをオーバーライドすることは違法であるべきです。
(53) オプションの包含と継承の必要性を混同しないでください。オプションの包含を継承としてモデル化すると、クラスの急増につながります。
(54) 継承階層を作成するときは、再利用可能なコンポーネントではなく、再利用可能なフレームワークを作成するようにしてください。
(55) 設計で多重継承を使用する場合は、間違いがあったと想定してください。間違いを犯していない場合は、それを証明する必要があります。
(56) オブジェクト指向設計で継承が使用されている限り、次の 2 つの質問を自問してください: (1) 派生クラスは継承するものの特別な型ですか? (2) 基本クラスは派生クラスの一部ですか? ?
(57) オブジェクト指向設計で多重継承を見つけた場合は、基本クラスが実際に別の基本クラスの派生クラスになっていないことを確認してください。
(58) オブジェクト指向設計において、包含と関連性のどちらかを選択する必要がある場合は、包含を選択してください。
(59) クラスオブジェクトのブックキーピングにグローバルデータやグローバル関数を使用しないでください。クラス変数またはクラスメソッドを使用する必要があります。
(60) オブジェクト指向の設計者は、物理的な設計原則が論理的な設計を損なうことを許すべきではありません。ただし、論理設計に関する決定を行う際には、物理設計基準を使用することがよくあります。
(61) オブジェクトの状態を変更するためにパブリックインターフェースをバイパスしないでください。
PHPの現在のステータス：Web開発動向を見てくださいApr 13, 2025 am 12:20 AMPHPは、現代のWeb開発、特にコンテンツ管理とeコマースプラットフォームで依然として重要です。 1）PHPには、LaravelやSymfonyなどの豊富なエコシステムと強力なフレームワークサポートがあります。 2）パフォーマンスの最適化は、Opcacheとnginxを通じて達成できます。 3）PHP8.0は、パフォーマンスを改善するためにJITコンパイラを導入します。 4）クラウドネイティブアプリケーションは、DockerおよびKubernetesを介して展開され、柔軟性とスケーラビリティを向上させます。
PHP対その他の言語：比較Apr 13, 2025 am 12:19 AMPHPは、特に迅速な開発や動的なコンテンツの処理に適していますが、データサイエンスとエンタープライズレベルのアプリケーションには良くありません。 Pythonと比較して、PHPはWeb開発においてより多くの利点がありますが、データサイエンスの分野ではPythonほど良くありません。 Javaと比較して、PHPはエンタープライズレベルのアプリケーションでより悪化しますが、Web開発により柔軟性があります。 JavaScriptと比較して、PHPはバックエンド開発により簡潔ですが、フロントエンド開発のJavaScriptほど良くありません。
PHP対Python：コア機能と機能Apr 13, 2025 am 12:16 AMPHPとPythonにはそれぞれ独自の利点があり、さまざまなシナリオに適しています。 1.PHPはWeb開発に適しており、組み込みのWebサーバーとRich Functionライブラリを提供します。 2。Pythonは、簡潔な構文と強力な標準ライブラリを備えたデータサイエンスと機械学習に適しています。選択するときは、プロジェクトの要件に基づいて決定する必要があります。
PHP：Web開発の重要な言語Apr 13, 2025 am 12:08 AMPHPは、サーバー側で広く使用されているスクリプト言語で、特にWeb開発に適しています。 1.PHPは、HTMLを埋め込み、HTTP要求と応答を処理し、さまざまなデータベースをサポートできます。 2.PHPは、ダイナミックWebコンテンツ、プロセスフォームデータ、アクセスデータベースなどを生成するために使用され、強力なコミュニティサポートとオープンソースリソースを備えています。 3。PHPは解釈された言語であり、実行プロセスには語彙分析、文法分析、編集、実行が含まれます。 4.PHPは、ユーザー登録システムなどの高度なアプリケーションについてMySQLと組み合わせることができます。 5。PHPをデバッグするときは、error_reporting（）やvar_dump（）などの関数を使用できます。 6. PHPコードを最適化して、キャッシュメカニズムを使用し、データベースクエリを最適化し、組み込み関数を使用します。 7
PHP：多くのウェブサイトの基礎Apr 13, 2025 am 12:07 AMPHPが多くのWebサイトよりも優先テクノロジースタックである理由には、その使いやすさ、強力なコミュニティサポート、広範な使用が含まれます。 1）初心者に適した学習と使用が簡単です。 2）巨大な開発者コミュニティと豊富なリソースを持っています。 3）WordPress、Drupal、その他のプラットフォームで広く使用されています。 4）Webサーバーとしっかりと統合して、開発の展開を簡素化します。
誇大広告を超えて：今日のPHPの役割の評価Apr 12, 2025 am 12:17 AMPHPは、特にWeb開発の分野で、最新のプログラミングで強力で広く使用されているツールのままです。 1）PHPは使いやすく、データベースとシームレスに統合されており、多くの開発者にとって最初の選択肢です。 2）動的コンテンツ生成とオブジェクト指向プログラミングをサポートし、Webサイトを迅速に作成および保守するのに適しています。 3）PHPのパフォーマンスは、データベースクエリをキャッシュおよび最適化することで改善でき、その広範なコミュニティと豊富なエコシステムにより、今日のテクノロジースタックでは依然として重要になります。
PHPの弱い参照は何ですか、そしていつ有用ですか？Apr 12, 2025 am 12:13 AMPHPでは、弱い参照クラスを通じて弱い参照が実装され、ガベージコレクターがオブジェクトの回収を妨げません。弱い参照は、キャッシュシステムやイベントリスナーなどのシナリオに適しています。オブジェクトの生存を保証することはできず、ごみ収集が遅れる可能性があることに注意する必要があります。
PHPで__invoke Magicメソッドを説明してください。Apr 12, 2025 am 12:07 AM\ _ \ _ Invokeメソッドを使用すると、オブジェクトを関数のように呼び出すことができます。 1。オブジェクトを呼び出すことができるように\ _ \ _呼び出しメソッドを定義します。 2。$ obj（...）構文を使用すると、PHPは\ _ \ _ Invokeメソッドを実行します。 3。ロギングや計算機、コードの柔軟性の向上、読みやすさなどのシナリオに適しています。
ホットAIツール
Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ
AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。
Undress AI Tool
脱衣画像を無料で
Clothoff.io
AI衣類リムーバー
AI Hentai Generator
AIヘンタイを無料で生成します。
人気の記事
ホットツール
MantisBT
Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティング サービスをチェックしてください。
メモ帳++7.3.1
使いやすく無料のコードエディター
MinGW - Minimalist GNU for Windows
このプロジェクトは osdn.net/projects/mingw に移行中です。引き続きそこでフォローしていただけます。 MinGW: GNU Compiler Collection (GCC) のネイティブ Windows ポートであり、ネイティブ Windows アプリケーションを構築するための自由に配布可能なインポート ライブラリとヘッダー ファイルであり、C99 機能をサポートする MSVC ランタイムの拡張機能が含まれています。すべての MinGW ソフトウェアは 64 ビット Windows プラットフォームで実行できます。
PhpStorm Mac バージョン
最新(2018.2.1)のプロフェッショナル向けPHP統合開発ツール
SublimeText3 中国語版
中国語版、とても使いやすい
