経営情報システムのコード設計におけるコーディングの目的は何ですか?

コーディングの目的は、独自性、標準化、体系化です。コードはさまざまな目的物を数字や文字で表現したもので、システム開発においてコードを設計する目的は、独自性、標準化、体系化です。

コードでは、数字や文字を使用してさまざまな目的の実体を表現します。システム開発プロセスでコードを設計する目的は次のとおりです。

1. ユニークなコード化;

2. 標準化;

3. システム化。

コード設計の 6 つの原則

単一責任の原則

定義: 1 つの A クラス、またはインターフェースは 1 つの責任のみを最もよく担当します。

問題の原因: クラス T は、2 つの異なる責任 P1 と P2 を担当します。責任P1を変更する必要があり、Tクラスも変更する必要があるため、本来正常に動作していた責任P2の機能が誤動作する可能性があります。

解決策: 単一責任の原則に従います。対応する責任に対応する新しいクラスをそれぞれ作成します。こうすることで、クラスの変更による他の責任への影響を回避できます。

責任の増大に遭遇した場合、ロジックが十分に単純な場合にのみ、ルールに違反します。コード レベルでの単一責任の原則。クラス内のメソッドの数が十分に少ない場合にのみ、メソッド レベルで単一責任の原則に違反できます。

利点: クラスの複雑さは軽減されます。大幅に改善され、メンテナンス性も向上します。

Liskov 置換原則

# 基底クラスが使用される場合、そのサブクラスは任意に使用でき、これにより、サブクラスが基底クラスを完全に置換できることが保証されます。精神は実際には、継承メカニズムの制約と規範を具体化したものです。親クラスとサブクラスの特定の実装では、基本クラスをサブクラスに置き換えるときにプログラムの動作が問題を引き起こさず、正常に続行できるように、継承階層内の関係特性が厳密に制御されます。

継承については、親クラスが一連の仕様や規約を定義しており、すべてのサブクラスがこれに従う必要はありませんが、サブクラスがこれらの非抽象メソッドを任意に変更すると、継承システム全体に影響を及ぼします。損傷を与えます。

親クラスのメソッドを書き直す必要がある場合、より一般的な方法は、元の親クラスとサブクラスの両方がより一般的な基本クラスを継承し、元の継承関係を削除し、依存関係を使用することです。代わりに、集約、組み合わせ、その他の関係;

原則には、次の 4 つのレベルの意味が含まれます:

* サブクラスは、親クラスの抽象メソッドを実装できますが、非クラスの抽象メソッドをオーバーライドすることはできません。 -親クラスの抽象メソッド メソッド;

* サブクラスは独自の一意のメソッドを追加できます;

* サブクラスのメソッドが親クラスのメソッドをオーバーライドする場合、その仮パラメータはメソッドの入力パラメータが親クラスのメソッドの入力パラメータより大きい、より緩やか、より良い;

* サブクラスのメソッドが親クラスの抽象メソッドを実装する場合、メソッドの戻り値はそれよりも厳密になります親クラスの;

依存逆転の原則

定義: 高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方ともその抽象化に依存する必要があり、抽象化は詳細に依存しない; 詳細は抽象化に依存する必要があり、中心的な考え方は抽象化に依存することです;

問題の原因: クラス A はクラス B に直接依存します。クラス C の場合は、クラス A のコードを変更する必要があります。このシナリオでは、通常、クラス A は複雑なビジネス ロジックを担当する高レベル モジュールです。クラス B とクラス C は、基本原理の操作を担当する低レベル モジュールです。クラス A の場合は、変更すると、プログラムに不必要なリスクがもたらされます。

解決策: インターフェイス I に依存するようにクラス A を変更します。クラス B とクラス C はそれぞれインターフェイス I を実装します。クラス A はインターフェイス I を通じて間接的にクラス B とクラス C に接続します。これにより、クラス A を変更するコストが削減されます。確率;

実際には、通常、次の 3 つの点を行う必要があります。

* 低レベルのモジュールには、抽象クラスまたはインターフェイス、あるいはその両方が必要です。

*宣言された変数の型は、可能な限り抽象クラスまたはインターフェイスである必要があります。

#* 継承を使用する場合は、Liskov 置換原則に従います。

#インターフェイス分離原則

定義: クライアントは、必要のないインターフェイスに依存すべきではありません。あるクラスの別のクラスに対する依存関係は、最小のインターフェイスに基づく必要があります。そうしないと、インターフェイス汚染が発生します。クラス A は、インターフェイス I を通じてクラス B に依存します。 、クラス C はインターフェイス I を通じてクラス D に依存します。インターフェイス I がクラス A とクラス B の最小インターフェイスではない場合、クラス B とクラス D は必要のないメソッドを実装する必要があります。

の意味原則は次のとおりです: 単一のインターフェイスの場合、巨大で肥大化したインターフェイスを構築しないでください。インターフェイスをできる限り改良し、インターフェイス内のメソッドをできるだけ少なくするようにしてください。つまり、専用のインターフェイスを確立する必要があります。依存するすべての人のために巨大なインターフェイスを構築しようとするのではなく、各クラスを呼び出します。呼び出すクラス;

インターフェイスはできるだけ小さくする必要がありますが、制限があることに注意してください。インターフェースによりプログラミングの柔軟性が向上しますが、小さすぎるとインターフェースの数が最小限になり、設計が複雑になります。インターフェイスに依存するクラスのサービスをカスタマイズします。必要なメソッドのみを呼び出しクラスに公開し、必要のないメソッドは非表示にします。

ルール:

* インターフェイスは 1 つのサブモジュールまたはビジネス ロジックのみを提供し、カスタマイズを提供します。

* インターフェイスの外観をより簡潔にするために、ビジネス ロジックを通じてインターフェイス内のパブリック メソッドを圧縮します。

* 汚染されたインターフェイスは可能な限り変更します。変更のリスクが大きすぎる場合は、アダプター モードを使用して変換します。

* 特定のビジネスに応じて、ロジックを深く理解し、心を使って設計アイデアをコントロールしてください。

インターフェイスの分離を実装する方法には、主に 2 つの方法があります:

1. 委任の分離。新しいインターフェイス タイプを追加して顧客のリクエストを委任します。顧客とインターフェイスの間の直接の依存関係を分離することにより、システムのオーバーヘッドも増加することに注意してください;

##2. 多重継承を分離し、インターフェイスの多重継承を通じて顧客のニーズを実現します;

#ディミッターの法則

定義: オブジェクトは、他のオブジェクトについての知識を最小限にとどめるべきです。中心となる精神は、見知らぬ人と話さないことです。一般的な意味は、オブジェクトはクラスについての知識をあまり持たないほうがよいということです呼び出すためには結合して関連付ける必要があるため、クラス間の結合の度合いが減り、各クラスが他のクラスへの依存を最小限に抑えることができます。

合成と再利用の原則

原則は、継承ではなく可能な限り合成/集約を使用することです;

オープンと終了原則

定義: クラス、テンプレート、関数などのソフトウェア エンティティは、拡張や変更に対して閉鎖されるべきです;

解決策: ソフトウェアを変更する必要がある場合は、次のことを試みてください。ソフトウェア エンティティの動作を拡張します。変更を実装するために既存のコードを変更するのではなく、変更を実装します。

#単一責任の原則: 実装クラスは単一の責任を持つ必要があります。

• リヒター置換の原則: 継承システムを破壊しない;

• 依存関係逆転の原則: インターフェイス指向プログラミング;

• インターフェイス分離原則: インターフェイスを設計するときは注意してください 単純なもの;

• デミットの法則: 結合を減らす;

• 開閉原則: 一般的な概要、オープン拡張は可能、変更は禁止;

関連知識の詳細については、

PHP 中国語 Web サイト

をご覧ください。

以上が経営情報システムのコード設計におけるコーディングの目的は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。