「クラスの代わりにマップを使用してデータを表現する」-リッチヒッキー

でリッチヒッキーことで、このビデオ、Clojureの作成者、彼はJavaで行ったように、代わりにそれを表現するためにクラスを使用してのデータを表現するためにマップを使用することを助言します。単にマップとして表されている場合、APIユーザーはどのように入力キーを知ることができるのか、私はそれがどのように改善できるのか理解していません。

例：

PersonAPI {
    Person addPerson(Person obj);
    Map<String, Object> addPerson(Map<String, Object> personMap);
}

2番目の関数では、APIユーザーはどのようにして人を作成するための入力を知ることができますか？

Exagg'itive Summary ^（TM）

いくつかのものがあります。

• プロトタイプの継承とクローニング
• 新しいプロパティの動的な追加
• 同じクラスの異なるバージョン（仕様レベル）のオブジェクトの共存。
  • より新しいバージョン（仕様レベル）に属するオブジェクトには、追加の「オプション」プロパティがあります。
• 新旧のプロパティの内観
• 検証ルールのイントロスペクション（以下で説明）

致命的な欠点が1つあります。

• コンパイラは、スペルミスの文字列をチェックしません。
• 自動リファクタリングツールは、プロパティキーの名前を変更しません-豪華なものにお金を払わない限り。

大事なのは、イントロスペクションを使用してイントロスペクションを取得できるということです。これは通常起こることです：

• リフレクションを有効にします。
• 大規模なイントロスペクションライブラリをプロジェクトに追加します。
• さまざまなオブジェクトメソッドとプロパティを属性または注釈でマークします。
• イントロスペクションライブラリに魔法をかけてみましょう。

言い換えれば、FPとのインターフェースが必要ない場合は、Rich Hickeyのアドバイスを受ける必要はありません。

最後になりましたがString、プロパティキーとして使用するのが最も簡単な意味を持ちますがString、s を使用する必要はありませんが、少なくとも（最もきれいではありません）。Android™を含む多くのレガシーシステムは、フレームワーク全体で整数IDを広範囲に使用して、クラス、プロパティ、リソースなどを参照します。

_{AndroidはGoogle Inc.の商標です。}

両方の世界を幸せにすることもできます。

Javaの世界では、通常どおりゲッターとセッターを実装します。

FPの世界では、

• Object getPropertyByName(String name)
• void setPropertyByName(String name, Object value) throws IllegalPropertyChangeException
• List<String> getPropertyNames()
• Class<?> getPropertyValueClass(String name)

これらの関数の中には、いや、見苦しいコードがありますが、それを埋めるIDEプラグインがあります。コードを読み取るスマートプラグインです。

物事のJava側は、通常と同じようにパフォーマンスが向上します。コードのcodeい部分は決して使用しません。Javadocから非表示にすることもできます。

世界のFP側は、必要な「リート」コードを何でも記述できます。通常、コードが遅いことについては怒りません。

一般に、オブジェクトの代わりにマップ（プロパティバッグ）を使用することは、ソフトウェア開発では一般的です。関数型プログラミングや特定の種類の言語に固有のものではありません。特定の言語に対する慣用的なアプローチではないかもしれませんが、それを必要とする状況があります。

特に、シリアル化/逆シリアル化には多くの場合、同様の手法が必要です。

「オブジェクトとしてのマップ」に関する一般的な考え方。

1. そのような「オブジェクトとしてのマップ」を検証するための関数を提供する必要があります。違いは、「オブジェクトとしてマップ」により、より柔軟な（制限の少ない）検証基準が可能になることです。
2. 「オブジェクトとしてのマップ」に追加フィールドを簡単に追加できます。
3. 有効なオブジェクトの最小要件の仕様を提供するには、以下が必要です。
   • マップで予想される「最低限必要な」キーのセットをリストする
   • 値を検証する必要があるキーごとに、値検証関数を提供します
   • 複数のキー値をチェックする必要がある検証ルールがある場合は、それも提供します。
   • 利点は何ですか？このように仕様を提供することは内省的です。最小限必要なキーのセットを照会し、各キーの検証関数を取得するプログラムを作成できます。
   • OOPでは、これらすべてが「カプセル化」という名前でブラックボックスにロールアップされます。機械可読な検証ロジックの代わりに、呼び出し元は人間が読める「APIドキュメント」のみを読み取ることができます（幸いなことに存在する場合）。

それは彼が何について話しているかを本当に知っている誰かによる素晴らしい話です。読者はすべてを読むことをお勧めします。長さはわずか36分です。

彼の主なポイントの1つは、シンプルさは後に変更の機会を開くということです。を表すクラスを選択すると、Person指摘したように静的に検証可能なAPIを作成することの利点がすぐに得られますが、機会を制限したり、後で変更や再利用のコストを増やしたりするコストが伴います。

彼のポイントは、クラスを使用することは合理的な選択かもしれませんが、コストを十分に認識して意識的に選択する必要があることであり、プログラマーは伝統的に、それらのコストを考慮することはもちろん、それらのコストに気付くという非常に貧弱な仕事をします。要件が大きくなるにつれて、その選択を再評価する必要があります。

以下は、Personオブジェクトのリストを使用する場合と比較して、マップのリストを使用する方が潜在的に簡単な、いくつかのコード変更です（1つまたは2つはトークで言及されました）。

• 人をRESTサーバーに送信する。（Mapプリミティブを送信可能な形式にするために作成された関数は、非常に再利用可能であり、ライブラリで提供されることもあります。Personオブジェクトは、同じジョブを実行するためにカスタムコードを必要とする可能性があります）。
• リレーショナルデータベースクエリからユーザーのリストを自動的に作成します。（繰り返しますが、1つの汎用かつ高度に再利用可能な関数）。
• 人を表示および編集するためのフォームを自動的に生成します。
• 一般的な機能を使用して、学生と従業員など、非常に不均質な個人データを処理します。
• 特定の郵便番号に居住するすべての人のリストを取得します。
• そのコードを再利用して、特定の郵便番号のすべてのビジネスのリストを取得します。
• 他のクライアントに影響を与えることなく、顧客固有のフィールドを個人に追加します。

この種の問題を常に解決し、それらのパターンとツールを用意していますが、最初からよりシンプルで柔軟性のあるデータ表現を選択することで作業が容易になった場合、考え続けることはほとんどありません。

• 変更される可能性のある柔軟なコンテンツで、データの動作がほとんどまたはまったくない場合は、マップを使用します。IMOは、N個のフィールド、N個のセッター、およびN個のゲッターを持つ貧血ドメインモデルで構成される典型的な「javabean」または「データオブジェクト」であり、時間の無駄です。豪華な構造でラップすることで、栄光に満ちた構造で他の人を感動させようとしないでください。正直に、あなたの意図を明確にし、マップを使用してください。（または、ドメイン、JSONまたはXMLオブジェクトに意味がある場合）

• データに重要な実際の動作（別名メソッド（Tell、Don's Ask））がある場合は、クラスを使用します。そして、実際のオブジェクト指向プログラミングを使用するために背中を叩いてください:-)。

• データに多くの重要な検証動作と必須フィールドがある場合は、クラスを使用します。

• データの検証動作が中程度であれば、それは境界線です。

• データがプロパティ変更イベントを発生させる場合、それは実際には簡単であり、Mapの面倒ははるかに少ないです。ちょっとしたサブクラスを書くだけです。

• Mapを使用する主な欠点の1つは、ユーザーが値をStrings、int、Foosなどにキャストする必要があることです。これが非常に面倒でエラーが発生しやすい場合は、クラスを検討してください。または、関連するゲッターでマップをラップするヘルパークラスを検討します。

のAPIにmapは2つのレベルがあります。

1. マップ用のAPI。
2. アプリケーションの規則。

APIは、慣例によりマップに記述できます。たとえば、ペア:api api-validateをマップに配置したり:api-foo validate-foo、慣例にすることができます。マップは保存することもできapi api-documentation-linkます。

規則を使用すると、プログラマーは、マップとして実装された「タイプ」全体のアクセスを標準化するドメイン固有の言語を作成できます。を使用(keys map)すると、実行時にプロパティを決定できます。

マップには魔法のようなものはなく、オブジェクトには魔法のようなものはありません。それはすべてディスパッチです。