(A) 「10 個のデータ構造で 10 個の関数を実行するよりも、1 つのデータ構造で 100 個の関数を実行する方がよい。」—アラン・ペルリス
(B) Clojure には defProtocol、defRecord、defType がある
両方の利点を得る Clojure プログラミングのスタイルはありますか?
(B) には、型エラーを回避できるという利点があります。
(A) には、重複コードを避けるという利点があります。
ありがとう
PS: 反対票を投じられた理由と、質問を再構築して生産的なものにする方法について、建設的な批判を聞きたいです。
(A) と (B) をどのように関連づけることができるかわかりません。
(A) 一貫性を保つことです。つまり、同じデータ構造を使用してアプリケーションのさまざまなレイヤーでデータ (たとえば、マップに格納されているユーザー情報) を表すと、一貫性が保たれます。多くのデータ構造を使用して同じ情報を表す場合、構造をある形式から別の形式に変換するコードを記述する必要があります。また、異なる構造で機能するさまざまな関数は、異なるデータ構造を想定しているため、構成できません。
(B) これは、Clojure のさまざまな構造に関するものです。
defprotocol: これはデータ構造に関するものではなく、コントラクト/インターフェイスに関するものです。つまり、特定の型がコントラクトを実装し、コントラクトを実装するためにコンシューマー関数が渡された型を必要とする任意のコンテキストで型を使用できます。例: コンソール (またはその他の書き込み可能な文字列) に出力できるタイプはすべて、印刷コントラクト/プロトコルを実装します。
defrecord: マップを作成しますが、デフォルトの方法で実装されたいくつかの追加インターフェースを使用します。
deftype: 型を作成するための低レベルの構造であるため、このために多くのコードを記述する必要があります。ほとんどの場合、これを使用する必要はありません。
これを調整する方法は、「データ型」ではなく「抽象化」を考えることです。または、Alan Perlisを言い換えると：
「10個の抽象化で10個の関数を実行するよりも、1個の抽象化で100個の関数を操作する方が適切です。」
したがって、Clojureの方法は次のとおりです。