7

Working on a project that parses a log of events, and then updates a model based on properties of those events. I've been pretty lazy about "getting it done" and more concerned about upfront optimization, lean code, and proper design patterns. Mostly a self-teaching experiment. I am interested in what patterns more experienced designers think are relevant, or what type of pseudocoded object architecture would be the best, easiest to maintain and so on.

There can be 500,000 events in a single log, and there are about 60 types of events, all of which share about 7 base properties and then have 0 to 15 additional properties depending on the event type. The type of event is the 2nd property in the log file in each line.

So for I've tried a really ugly imperative parser that walks through the log line by line and then processes events line by line. Then I tried a lexical specification that uses a "nextEvent" pattern, which is called in a loop and processed. Then I tried a plain old "parse" method that never returns and just fires events to registered listener callbacks. I've tried both a single callback regardless of event type, and a callback method specific to each event type.

I've tried a base "event" class with a union of all possible properties. I've tried to avoid the "new Event" call (since there can be a huge number of events and the event objects are generally short lived) and having the callback methods per type with primitive property arguments. I've tried having a subclass for each of the 60 event types with an abstract Event parent with the 7 common base properties.

I recently tried taking that further and using a Command pattern to put event handling code per event type. I am not sure I like this and its really similar to the callbacks per type approach, just code is inside an execute function in the type subclasses versus the callback methods per type.

The problem is that alot of the model updating logic is shared, and alot of it is specific to the subclass, and I am just starting to get confused about the whole thing. I am hoping someone can at least point me in a direction to consider!

4

5 に答える 5

3

ええと...すべてのプロパティの結合を持つ単一のイベント クラス、または 61 のイベント クラス (1 つのベース、60 のサブ) ではなく、非常に多くのバリエーションがあるシナリオでは、単一のイベント クラスを使用したくなるでしょう。イベント情報を格納するためにプロパティ バッグ (辞書、ハッシュ テーブル、w/e フロート ボート) を使用するイベント クラス。イベントのタイプは、バッグに入れられるもう 1 つのプロパティ値です。私がそのように傾倒する主な理由は、何かの 60 の派生クラスを維持するのが嫌いだからです。

大きな問題は、イベントを処理するときに、イベントをどう処理する必要があるかということです。それらをレポートにフォーマットしたり、データベース テーブルに整理したり、特定のイベントが発生した場合に人々を目​​覚めさせたりしますか?

これは、事後パーサーまたはリアルタイム イベント ハンドラーを意図したものですか? つまり、イベントが発生したときにログを監視していますか、それとも次の日にログ ファイルを解析しているだけですか?

于 2008-09-18T16:34:19.070 に答える
2

イベントの「クラス」ごとに 1 つずつ、Strategy オブジェクトの Flyweight ファクトリを考えてみましょう。

イベント データの行ごとに、flyweight ファクトリから適切な解析戦略を検索し、解析のためにイベント データを戦略に渡します。60 個の戦略オブジェクトのそれぞれが同じクラスである可能性がありますが、フィールド解析オブジェクトの異なる組み合わせで構成されています。詳細がなければ、より具体的にするのは少し難しいです。

于 2008-09-18T16:34:13.203 に答える
1

ちょうど上から：

プロパティのマップを持つクラスを1つだけ持つという、受け入れられた回答の提案が好きです。また、動作は次のように組み立てることもできると思います。

class Event
{
    // maps property name to property value
    private Map<String, String> properties;

    // maps property name to model updater
    private Map<String, ModelUpdater> updaters; 

    public void update(Model modelToUpdate)
    {
        foreach(String key in this.properties.keys)
        {
            ModelUpdater updater = this.updaters[key];
            String propertyValue = this.properties[key];

            updaters.updateModelUsingValue(model, propertyValue);
        }
    }

}

ModelUpdater クラスは描かれていません。プロパティに基づいてモデルを更新します。私はループを作りました。これは、実際のアルゴリズムである場合とそうでない場合があります。私はおそらく ModelUpdater をもっとインターフェースにしたいと思います。各実装者はプロパティごとになり、モデルを更新します。

次に、私の「メインループ」は次のようになります。

Model someModel;

foreach(line in logFile)
{
    Event e = EventFactory.createFrom(line);
    e.update(someModel);
}

EventFactory は、ファイルからイベントを構築します。イベントのプロパティに基づいて 2 つのマップを設定します。これは、プロパティをそれに関連付けられたモデル アップデータと一致させる何らかの方法があることを意味します。

派手なパターン名はありません。イベントにプロパティ A、B、および C がある場合のような複雑なルールがある場合、B のモデル アップデーターを無視する場合、このアプローチを何らかの方法で拡張する必要があります。ほとんどの場合、ルール オブジェクト パターンを使用して何らかのルールを EventFactory に挿入する必要があります。ほら、あなたのためのパターン名があります！

于 2008-10-20T21:29:41.090 に答える
1

ハッシュ化されたアダプター オブジェクトの可能性があります (Web で適切な説明を見つけることができれば、不足しているようです)。

于 2008-09-18T16:34:10.100 に答える
0

問題を正しく理解しているかどうかわかりません。複雑な「モデル更新ロジック」があると思います。これを 60 個のクラスに分散せず、1 か所に保持し、イベント クラス (メディエーター パターンなど) から移動します。

Mediator はイベント クラスで動作し (ここで Flyweight を使用する方法がわかりません)、イベントはそれ自体を解析できます。

更新ルールが非常に複雑な場合、汎用プログラミング言語で問題に実際に取り組むことはできません。ルールベースのエンジンなどを使用することを検討してください。

于 2008-09-18T19:56:37.147 に答える