3

システムにいくつかの大きな変更を行っています。SOLID の原則を尊重して、これらの新しいビジネス ロジック ルールを実装する最善の方法を知りたいです。

オープン/クローズの原則は、「拡張にはオープン、変更にはクローズ」と言いますが、変更するにはどうすればよいですか? つまり、古いビジネス ロジックを保持したくないということです。私の考えでは、「拡張」は主に「コードを変更する」ではなく「コードを追加する」ことを意味します。

4

3 に答える 3

2

Open / Closedの背後にある考え方は、異なるビジネスロジックが必要な場合は、新しいビジネスロジッククラスを作成する必要があるということです。

ただし、これの主な動機は、そこにある既存のコードに影響を与えたり、再テストしたり、再度サインオフしたりしたくないということです。使用しているビジネスロジックが根本的に変更された場合、すべての参照を次のように変更します。新しいオブジェクトと古いオブジェクトを廃止する場合、この場合、オブジェクトを再度開いて変更することができます。重要なのは、（1）とにかくすべてのコードを再テストする必要があり、（2）古いオブジェクトはどこにも使用されないということです。

HTH、ジェームズ

于 2010-08-24T15:47:18.593 に答える
1

2 つの大きな質問:

ここでは、どのような変化について話しているのでしょうか。

どのような既存のコードがありますか? すでにSOLIDの原則に準拠していますか?

適切に設計された既存のアプリケーションに変更を加える必要があるとします。おそらく給与アプリケーションを考えてみましょう。Interafce があるかもしれません (これは不自然な例です)

 public Interface EmployeeContract {         
      public int computeSalaryForMonth(int month);
 }

そして実装があります：

 public class SalesContract implements EmployeeContract {
      public int computeSalaryForMonth(int month){
               // computation involving sales figures and base salary
      }
 }

  public class HourlyContract implements EmployeeContract {
      public int computeSalaryForMonth(int month){
               // computation involving hours worked and overtime payments
      }
 }

これで、アプリケーションの他のすべての部分が、インターフェースに関してコーディングされました。

既存のコードを変更せずに、新しい種類のコントラクトを追加できるようになりました。拡張が可能で、非常に複雑な新しいビジネス ロジックを追加できる可能性があります。

しかし、それは元の設計者がそのような変化を予期しており、新しい月額契約タイプを追加したためです. 週払いの従業員を採用したいのであれば、あまり良くありませんか? インターフェースが適切ではないため、変更する必要があり、その影響が他のコードに波及します。

現実的には、ソフトウェアは任意のビジネス ロジックを簡単に変更できるわけではありません。ただし、私の例では、インターフェイスは必要なほど柔軟ではありませんが、インターフェイスは結合点であるため、コードの変更が必要な部分を簡単に特定できることに注意してください。

要約：あなたの状況では：

  1. 既存のコードの構造と、どこに柔軟性があるかを理解します。一部のコードを変更する必要があること、およびビジネスの大幅な変更によってコードの大幅な変更が必要になることは当然のことであることを受け入れてください。
  2. 通常、構造は保守性に役立ちます。そのため、新しいコードを追加するときは構造に注意してください。インターフェースにコーディングすることでコードに「ファイアウォール」を提供し、仕事の遂行と拡張への開放との間のバランスをとります。
于 2010-08-24T15:44:08.957 に答える
0

オープンクローズの原則とは、現在のコードを変更する必要がないことを意味するため、変更はクローズされますが、新しい要件を満たすためには、サブクラスを使用してコードを拡張し、インターフェイスを実装し、パターンを設計して、コードがこのアクティビティに対してオープンになるようにする必要があります。原因として、リファクタリング中にコードを変更する必要があることに直面するでしょうが、OSP を満足させる方法でそれを行う必要があります。

たとえば、コードの周りに散在する同様のオブジェクトの新しいインスタンスを作成する代わりに、ファクトリ メソッドを作成できます。新しい要件が 1 つの新しいオブジェクトを追加するようになると、コードは変更のために閉じられます (コード内に新しいインスタンスはありません) が、変更のために開かれます (ファクトリ メソッドを拡張します)。

于 2010-08-24T15:43:54.887 に答える