适当的事件日志解析器设计模式？
处理解析事件日志的项目，然后根据这些事件的属性更新模型。 我一直懒得“完成它”，更关心前期优化，精益代码和适当的设计模式。 主要是自学实验。 我感兴趣的是更有经验的设计师认为相关的模式，或者哪种类型的伪编码对象架构是最好的，最容易维护的等等。
单个日志中可以有500,000个事件，大约有60种类型的事件，所有这些事件共享大约7个基本属性，然后根据事件类型具有0到15个其他属性。 事件类型是每行日志文件中的第二个属性。
因此，我尝试了一个非常丑陋的命令式解析器，逐行遍历日志，然后逐行处理事件。 然后我尝试了一个使用“nextEvent”模式的词法规范，该模式在循环中被调用并被处理。 然后我尝试了一个简单的旧“解析”方法，该方法永远不会返回，只是将事件触发到已注册的侦听器回调。 无论事件类型如何，我都尝试过一次回调，以及特定于每种事件类型的回调方法。
我已经尝试了一个带有所有可能属性的联合的基础“事件”类。 我试图避免“新事件”调用（因为可能存在大量事件并且事件对象通常是短暂的）并且具有带有原始属性参数的每种类型的回调方法。 我已经尝试为60个事件类型中的每一个创建子类，并使用具有7个公共基本属性的抽象事件父类。
我最近尝试进一步使用命令模式为每个事件类型放置事件处理代码。 我不确定我是否喜欢这个并且它与每种类型的回调方法非常相似，只是代码在类型子类中的执行函数内，而不是每种类型的回调方法。
问题是很多模型更新逻辑是共享的，而且很多都是特定于子类的，我只是开始对整个事情感到困惑。 我希望有人能够至少指出我的方向来考虑！
嗯…对于一件事而不是一个具有所有属性的联合的事件类，或者61个事件类（1个基数，60个子），在具有如此多变化的场景中，我很想拥有一个使用属性包（字典，哈希表，w / e浮动你的船）的事件类来存储事件信息。 事件的类型只是一个属性值，可以放入包中。 我倾向于这种方式的主要原因只是因为我不愿意维护任何东西的60个派生类。
最大的问题是……当您处理事件时，您与事件有什么关系。 您是否将它们格式化为报表，将它们组织到数据库表中，如果发生某些事件则唤醒人们……什么？
这是一个事后解析器，还是一个实时事件处理程序？ 我的意思是，您是在事件进入时监控日志，还是仅在第二天解析日志文件？
考虑一个策略对象的Flyweight工厂，每个“一类”事件。
对于每行事件数据，从flyweight工厂查找适当的解析策略，然后将事件数据传递给策略进行解析。 60个策略对象中的每一个都可以是同一个类，但配置了不同的字段解析对象组合。 没有更多细节，有点难以更具体。
可能是哈希的适配器对象 （如果你能在网上找到它的一个很好的解释 – 它们似乎缺乏。）
就在顶部：
我喜欢接受的答案中关于只有一个带有属性映射的类的建议。 我也认为behvavior也可以这样组装：
class Event { // maps property name to property value private Map properties; // maps property name to model updater private Map 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从文件构造事件。 它根据事件的属性填充两个映射。 这意味着有某种方法可以将属性与其关联的模型更新程序进行匹配。
我没有任何花哨的图案名称。 如果你有一些复杂的规则，比如一个事件有属性A，B和C，那么忽略B的模型更新器，那么必须以某种方式扩展这种方法。 最有可能的是，您可能需要使用规则对象模式以某种方式将一些规则注入EventFactory。 你去，有一个模式名称给你！
我不确定我是否正确理解了这个问题。 我假设有一个复杂的’模型更新逻辑’。 不要通过60个类分发它，将它保存在一个地方，将它从事件类中移出（Mediator模式，类型）。
你的调解员将使用事件类（我不知道你怎么能在这里使用Flyweight），事件可以解析自己。
如果更新规则非常复杂，则无法使用通用编程语言来解决问题。 考虑使用基于规则的引擎或类似的东西。