2

この質問を正しく表現できることを願っています。静的およびインスタンスの可変フィールドを持つクラスで状態とテスト機能を扱うときに懸念があります。

静的フィールドは、有効期間/スコープの違いにより、本質的に異なるクラス/責任/インスタンスを構成しますか?

もしそうなら、インスタンスフィールドも別のクラス/データ構造であるべきではありませんか?

そして、もしそうなら、すべてのクラスは、構築時に依存関係を受け取るだけでステートレスであるべきではなく、すべて不変であるべきではないでしょうか?

そして最後に、これは関数型プログラミングがオブジェクト指向プログラミングを行う正しい方法であることを意味するのでしょうか?

4

1 に答える 1

3

(本当に) 変更可能な静的フィールドを持つべきではありません。それは安っぽいデザインです。関数型プログラミングは物事をずっと簡単にします。私は懸念を次のように分けます：

  • データとは何か、クラスでそれを操作するために必要なコードのみを持つ必要があります。"string" "Integer" "Person" のように、これらはエンティティです
  • データを操作するものはデータに依存しますが、内部状態を持つべきではありません (フォーマッターなど)
  • 実行を駆動するものは、通常、何らかの内部状態を持っている必要がありますが、呼び出しで実行されるか、データベース接続、要求などの「構成」です。これは、アクティブな要求からのものであるか、純粋な構成 (注入) です。
  • どのビューの結果 (純粋なビュー) はそれ自体ステートレスであり、状態はコンテキストでそれに供給される必要があります
  • それから間に接着剤があり、通常は毛むくじゃらの例外です..それを最小限に抑えます.

等..

テスト容易性のために

  • データは偽のデータベースにモックできる必要があります。
  • 「データを操作するもの」はステートレスであるため、簡単にテストできます。
  • コンテキストに含まれる状態は簡単にモックできます。
  • 依存関係は注入可能であり、少しずつテストできるため、「実行を駆動するもの」は簡単にテストできるはずです。
  • モック状態をフィードできるため、ビューは簡単にテストできます。難しさは、「どのように見えるか」を実際に検証することにありますが、それは GUI 自動化または人間のテスター次第です。

基本的に、データベース (ディスク) と要求レイヤー (Web、UI など) が準拠していれば、これらすべてを機能的な方法で実行できます。実際には、「純粋な」部分をかわいらしく機能的にするようにし、デザイン パターンを使用して外部の汚れから保護します。

于 2012-08-07T19:04:13.440 に答える