新しいモジュールを構築するつもりであるが、最初に、それらが満たさなければならないテンプレート (インターフェース/コントラクト) を定義したい場合、動作を使用する必要がありますか、それともより好ましい解決策がありますか? 明らかに、後でその機能のさまざまな実装をドロップできるように、[重要な] モジュールを構築したいと考えています。
適切で効率的な習慣を身につけていることを確認したいのですが、検索でそのテーマに関する即時の有用な情報が得られません。
ありがとう。
新しいモジュールを構築するつもりであるが、最初に、それらが満たさなければならないテンプレート (インターフェース/コントラクト) を定義したい場合、動作を使用する必要がありますか、それともより好ましい解決策がありますか? 明らかに、後でその機能のさまざまな実装をドロップできるように、[重要な] モジュールを構築したいと考えています。
適切で効率的な習慣を身につけていることを確認したいのですが、検索でそのテーマに関する即時の有用な情報が得られません。
ありがとう。
erlang では、モジュールに同じ型の同じメソッドを持たせるだけで十分です。特定の種類の仕様および/またはコントラクトが存在することを確認したい場合は、R15 機能をビヘイビアとともに使用し-callback
、ダイアライザーがチェックできる型仕様を作成できます。それとは別に、通常の良いアイデアが適用されます。つまり、抽象化から取得した値をモジュール外の抽象として見なします。そうでなければ、単純なドロップイン交換はそれほど効果的ではありません.
私はしばしばインターフェースモジュールを持つことで erlang で抽象化します。application を書いているとしましょうfoo
。私はしばしばモジュールを持っていますfoo
が、このモジュールはアプリケーションを使用する唯一の方法です。他の方法でアプリケーションを呼び出すことはできません。大規模なシステムの場合、公開されるモジュールが増えますが、基本的な考え方は、公開リストを小さく保つことです。
これにより、ファクタリングされたモジュールの背後にあるものを必要に応じて書き換えることができます。プロセスの追加、監視ツリーの変更などを決定できます。
Erlang で重要なのは、多くの場合、プロセス間のプロトコルを指定することです。そして、それを安定させてください。プロセスは状態を共有できないため、プロトコルはデカップリングを強制します。これは、後でコードの一部を再設計する場合に役立ちます。
ビヘイビアは基本的に唯一のオプションです:(私はこの目的のためにビヘイビアを頻繁に使用しますが、代わりにMLファンクターに似たものを本当に望んでいます.
モジュール スケール未満のインターフェイスの場合、型注釈付きの高次関数があり、これも最適ではありません。