删除对日志记录代码的依赖
我有更多类似设计的问题，因为我正在重构我接管的相当大的代码。
它不是模块化的，基本上它是伪面向对象的代码。它包含硬编码的依赖项、没有接口、多重职责等。只是混乱。
其中，它包含对名为 Audit 的类的大量内部调用，其中包含 Log、Info、LogError 等方法......该类必须在应用程序中配置配置才能工作，否则会崩溃。这对我来说是主要的痛苦。请让我们在响应中重点讨论这个问题，即使客户端代码独立于日志记录类/解决方案/框架。
现在，我希望对那些具有 Audit 类依赖项进行硬编码的类进行重构，以获得几个好处：
- 首先是将它们很好地提取到不同的程序集中，因为我需要一些可用的功能其他应用程序（例如生成附件代码 - 让我们将其称为 AttachmentsGenerator 类，到目前为止该类特定于一个应用程序，但现在该代码可以在许多地方使用）
- 删除内部依赖项，以便其他应用程序将利用我的 AttachmentsGenerator 类，而无需添加对其他类的引用
- 做一个魔术，以便允许 AttachmentsGenerator 类报告一些审核信息、跟踪等。但是我不希望它有硬编码的实现。事实上，我不希望它是强制性的，因此可以在没有配置内部日志记录的情况下使用 AttachmentsGenerator ，并且客户端代码不需要添加对另一个程序集的引用为了使用日志记录。底线：如果客户端代码想要使用 AttachmentsGenerator，它会添加对包含该类的程序集的引用，然后使用 new 运算符，仅此而已。
我可以在设计模式等方面使用什么样的方法来实现它？我希望获得一些解决该问题的文章的链接 - 因为在回答中阐述想法可能非常耗时。或者您是否可以建议简单的接口/类/装配草图。
多谢， Paweł
编辑 1：由于我的问题不太清楚，我会再次改述：这是我的计划，还有其他有趣的方法吗？
I have more like desing question as I'm refactoring quite big piece of code that I took over.
It's not modular, basically it's pseudo-object-oriented code. It contains hard coded dependencies, no interfaces, multiple responsibilities etc. Just mayhem.
Among others it contains a great deal of internal calls to class called Audit, that contains methods like Log, Info, LogError etc... That class has to be configured in application config in order to work, otherwise it's crash. And that's the main pain for me. And please, let's focus on that issue in responses, namely making client code independent of logging classes/solutions/frameworks.
And now, I would like those classes, that have that Audit class dependency hardcoded, refactored in order to obtain several benefits:
- First is to extract them nicely to different assemblies, as I will need some functionality available in other applications (for instance generating attachments code - let's call it AttachmentsGenerator class, that until now was specyfic to one application, but now that code could be used in many places)
- Remove internal dependencies so that other application that will take advantage of my AttachmentsGenerator class without the need to add reference to other
- Do a magic trick in order to allow AttachmentsGenerator class to report some audit info, traces etc. But I don't want it to have hardcoded implementation. As a matter of fact, I don't want it to be mandatory, so it would be possible to use AttachmentsGenerator without that internal logging configured and without the necessity for the client code to add reference to another assemblies in order to use logging. Bottom line: if client code wants to use AttachmentsGenerator, it adds reference to assembly that contains that class, then it uses new operator and that's all.
What kind approach can I use in terms of design patterns etc to achieve it? I would appreciate some links to articles that address that issue - as it can be timeconsuming to elaborate ideas in answer. Or if you can suggest simple interface/class/assembly sketch.
Thanks a lot,
Paweł
Edit 1: As my question is not quite clear, I'll rephrase it once again: This is my plan, are there other interesting ways to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
似乎最简单的方法是使用依赖注入。
创建具有日志记录方法的通用
ILogger接口。创建
ILogger的具体实现，它对所有方法不执行任何操作（例如NullLogger）创建另一个具体实现，该实现实际上通过您选择的任何框架（例如 log4net）进行日志记录
使用 DI 工具（spring、结构图等）根据您是否希望启用日志记录来注入适当的实现。
Seems like the easiest way to do this would be to use dependency injection.
Create a generic
ILoggerinterface with methods for logging.Create a concrete implementation of
ILoggerthat just does nothing for all the methods (e.g.NullLogger)Create another concrete implementation that actually does logging via whatever framework you choose (e.g. log4net)
Use a DI tool (spring, structure map, etc.) to inject the appropriate implementation depending on whether or not you want logging enabled.
将日志记录（以及任何其他横切关注点）作为装饰器实现。这比必须向每个对象注入一些 ILogger 接口更加SOLID服务（这将违反单一职责原则和干）。
Implement logging (and any other cross-cutting concerns) as a Decorator. That's way more SOLID than having to inject some ILogger interface into each and every service (which would violate both the Single Responsibility Principle and DRY).