0

ネットワーク内で互いに通信して何らかのタスクを実行する複数の「プロセッサ」を持つシステムを設計しています。

実際、これは社内の複数のチームが使用するライブラリになるはずです。

Avro を使用して、プロセッサが受け入れる入力と出力のタイプを定義します。ここまでは順調ですね。しかし今、私の同僚の何人かは、int -> long (問題なし) または String -> int (いいえ!!!) などの変換を黙って実行することにより、単純な型に「より多くの柔軟性」を提供するよう働きかけています。アイデアは、Avro スキーマが Processor の動作を定義するというものですが、いくつかの単純なケースでは、int を String として出力する Processor が、int を必要とする Processor と通信できるようにする必要があります...

私たちはこれについて議論しており、私は次の議論で反対しています。

  1. 型の安全性を高める必要があり、利便性が後でバグの原因になる可能性があります。
  2. そのメカニズムでは、API は「あいまい」になり、プロセッサに送信できる/できないタイプが常に明確になるとは限りません。
  3. 最初の rev にそのメカニズムがなく、厳密な型定義が必要な場合は、いつでもそれを緩和して、後で「変換」を開始することができます。しかし、どういうわけか、これらの議論はうまくいかないようです。

その「変換」メカニズムの長所と短所は何ですか?

4

4 に答える 4

2

この議論は、技術的なメリットで勝ち負けすることはできないと思います。それはあまりにも多くの主観的な問題を含みます...この段階では。（たとえば、型変換に関連するAPIの不一致が問題になるという考えと同様に、柔軟性が必要になるという考えは主観的なものです。）

私が論争に対処する方法は、価値変換フレームワークには、通常のAvroのやり方に対する複雑な（コストがかかり、時間がかかり、潜在的にリスクがあり、長期的に維持するのが難しい）拡張が含まれることを指摘することです。これを使用してプロジェクトをフロントロードしないことをお勧めします。むしろ、複雑さが本当に必要になるかどうかを判断するのに十分な実際の機能が実装されるまで、それを延期します。

于 2012-09-20T00:46:43.007 に答える
1

プロセッサAPIが必要な/提供するタイプに関して強く型付けされている場合、コンパイル時に無料で多くのエラーチェックが行われます。これは非常に貴重です。人々が変換のサポートを主張する場合、この利点を失わないいくつかの（かなり簡単に実装できる）アイデアを考えることができます。

  1. プロセッサのネットワークを構築する場合、呼び出し元は、適切な変換を行う「接着剤」プロセッサを明示的に提供する必要があります。たとえば、が入力タイプと出力タイプProcessor<I,O>のプロセッサを表す場合、呼び出し元は文字列から整数に変換するプロセッサを提供します。IO

  2. フレームワークには、「型コンバーターレジストリ」（のようなものMap<Pair<Class<I>,Class<O>>,Transformer<I,O>>）を含めることができます。これには、一連の標準変換が含まれ、ユーザーは新しい変換を追加することもできます。プロセッサのネットワークを構築する開発者は、厳密な型指定（上記の＃1）を使用するか、フレームワークにレジストリから型変換プロセッサを自動的に選択させるかを選択できます。

于 2012-09-20T00:59:11.097 に答える
1

Java API のユーザーは、Java の動作を期待していると思います。

于 2012-09-20T00:32:00.087 に答える
1

堅牢性の原則がここで役立つと思います。

行うことには保守的であり、他者から受け取るものには寛容である (「送信するものには保守的であり、受け取るものには寛容である」と言い換えられることがよくあります)。

とはいえ、必要のないコードを書くことはお勧めしません。あなたが提案している方法でそれを実行しないのはなぜですか。システムが相手が提案している追加の機能を必要とする場合は、あなたが提案したように後で追加しますか? 彼らがこれを理解できない場合、私は彼らがあなたの話を聞いているかどうか本当に疑問に思い、おそらくあなたの主張を言い換える方法を考えます.

于 2012-09-20T00:37:25.870 に答える