オブザーバーパターンに基づいてAPIを提供したいパッケージを設計しています。つまり、ゼロ以上の利害関係者をトリガーするシグナルを送信したいポイントがあります。それらの利害関係者は、必ずしもお互いについて知る必要はありません。
このようなAPIを最初から実装できることは知っていますが（たとえば、チャネルのコレクションやコールバック関数を使用して）、そのようなAPIを構造化するための好ましい方法があるかどうか疑問に思いました。
私が遊んだ多くの言語やフレームワークでは、これらのAPIを構築して、ユーザーが期待するとおりに動作するようにする標準的な方法があります。たとえば、g_signal_*glibベースのアプリケーション、イベント、addEventListener()JavaScript DOMアプリの関数、または。ネット。
Goに似たものはありますか？そうでない場合は、Goでより慣用的なこのタイプのAPIを構築する他の方法はありますか？
チャネルから受信するゴルーチンは、ある程度オブザーバーに類似していると言えます。したがって、Goでイベントを公開する慣用的な方法は、パッケージ（関数）からチャネルを返すIMHOです。もう1つの観察結果は、Goプログラムではコールバックがあまり頻繁に使用されないことです。その理由の1つは、強力なの存在でもありselect statementます。
最後に、一部の人々（私も）はGoFパターンをGoアンチパターンと見なしています。
Goは、シグナルAPIを設計するための多くのツールを提供します。
まず、いくつかのことを決定する必要があります。
プッシュモデルとプルモデルのどちらが必要ですか？例えば。パブリッシャーはイベントをサブスクライバーにプッシュしますか、それともサブスクライバーはパブリッシャーからイベントをプルしますか？
プッシュシステムが必要な場合は、サブスクライバーにメッセージを送信するためのチャネルをパブリッシャーに提供させると非常に効果的です。プルメソッドが必要な場合は、ミューテックスで保護されたメッセージボックスだけが機能します。それ以外は、要件について詳しく知らなければ、詳細を説明するのは困難です。
いくつかのプロジェクトで「オブザーバーパターン」タイプのものが必要でした。 これは最近のプロジェクトからの再利用可能な例です。
それはそれを使用する方法を示す対応するテストを持っています。
基本的な理論は、何か面白いことが起こったときはいつでも、イベントエミッターがSubmitデータの一部を呼び出すというものです。そのイベントを認識したいクライアントはRegister、イベントデータを読み取るチャネルになります。登録したこのチャネルは、selectループで使用することも、直接読み取る（またはバッファリングしてポーリングする）こともできます。
終わったら、あなたはUnregister。
すべての場合に完全ではありませんが（たとえば、遅いオブザーバーには強制登録解除タイプのイベントが必要な場合があります）、使用する場所では機能します。
チャネルは言語に組み込まれているため、これを行う標準的な方法はありません。チャネルを使って物事を行う標準的な方法を備えたチャネルライブラリはなく、単にチャネルがあります。ファーストクラスのオブジェクトにチャネルを組み込むことで、標準的な手法を使用する必要がなくなり、最も簡単で自然な方法で問題を解決できます。
https://github.com/chuckpreslar/emissionにNodeEventEmitterの基本的なGolangバージョンがあります
http://itjumpstart.wordpress.com/2014/11/21/eventemitter-in-go/を参照してください