This makes for interesting, ruby like, syntax. However, like John said, just because you can doesn't mean you should.
This would confuse most C# developers out there and add unneeded confusion.
For the the specific purposes of logging there are far better ways to get what you want. My very first question would be, why are you rolling your own logging solution? Logging is a very well solved problem and you shouldn't be wasting dev cycles on something that, log4net for instance, does just fine.
I'm gonna go with not a good idea. I can't think of any reason to do this. It clutters the namespace, and it isn't very intuitive. (At least to me)
EDIT
Now that I think about it, I have seen some advocate extending simple objects like this, but a logger isn't a good case IMHO. If you are providing a .ToX() functionality, like converting an integer to a MPH string or something like that, an extension method might be useful, but a logger is just not a good fit.
Normally instead of Console.WriteLine you have a call to your actual logging mechanism
Your logging API (if you are using one) could not only be able to log strings but also log any kind of objects. For example in log4net you can call .Error method with an object parameter. Then the logging mechanism decides what information about the object to actually log.
For proper logging, you would want far more than just some string. Date, source, category etc., which you may want to store in a more structured manner.
All in all, creating a logging extension method on String feels just plain wrong. The extension method's functionality should have a fairly strong association with the type it's operating upon, in line with the single responsibility principle. In the case as you described, that's clearly being violated.
The biggest problem in this approach is it is nearly impossible to inject dependencies into static/extension methods very cleanly. Meaning your logging solution (presuming it is to become more complex than dumping things to stdout/console/debug) has to be spun up and configured to do just about any sort of testing on the project. Ever.
发布评论
评论（7）
好吧，它们一开始就是静态的，这将使测试变得更加困难，并且将所有内容耦合得更紧密。
我个人也认为类似的东西
比
Well they're static for a start, which is going to make testing more difficult and will couple everything more tightly.
I also personally think something like
is more understandable than
对我来说，它的可读性不是很好。
仅仅因为你可以并不意味着你应该:)
To me, it isn't very readable.
Just because you can doesn't mean you should :)
这使得语法变得有趣、像 Ruby 一样。然而，正如约翰所说，仅仅因为你可以，并不意味着你应该这样做。
这会让大多数 C# 开发人员感到困惑，并增加不必要的混乱。
对于日志记录的特定目的，有更好的方法来获得您想要的东西。我的第一个问题是，你为什么要推出自己的日志记录解决方案？日志记录是一个很好解决的问题，您不应该在 log4net 等做得很好的事情上浪费开发周期。
This makes for interesting, ruby like, syntax. However, like John said, just because you can doesn't mean you should.
This would confuse most C# developers out there and add unneeded confusion.
For the the specific purposes of logging there are far better ways to get what you want. My very first question would be, why are you rolling your own logging solution? Logging is a very well solved problem and you shouldn't be wasting dev cycles on something that, log4net for instance, does just fine.
我会接受这不是一个好主意。我想不出有什么理由这样做。它使命名空间变得混乱，而且不太直观。 （至少对我来说）
编辑
现在我想起来了，我看到一些倡导者扩展这样的简单对象，但恕我直言，记录器不是一个好例子。如果您提供 .ToX() 功能，例如将整数转换为 MPH 字符串或类似的内容，则扩展方法可能有用，但记录器不太适合。
I'm gonna go with not a good idea. I can't think of any reason to do this. It clutters the namespace, and it isn't very intuitive. (At least to me)
EDIT
Now that I think about it, I have seen some advocate extending simple objects like this, but a logger isn't a good case IMHO. If you are providing a .ToX() functionality, like converting an integer to a MPH string or something like that, an extension method might be useful, but a logger is just not a good fit.
通常，您可以调用实际的日志记录机制，而不是
Console.WriteLine。您的日志记录 API（如果您正在使用）不仅可以记录字符串，还可以记录任何类型的对象。
例如，在 log4net 中，您可以使用对象参数调用
.Error方法。然后日志记录机制决定实际记录有关对象的哪些信息。
你的做法推翻了这个想法。
Normally instead of
Console.WriteLineyou have a call to your actual logging mechanismYour logging API (if you are using one) could not only be able to log strings but also log any kind of objects.
For example in log4net you can call
.Errormethod with an object parameter.Then the logging mechanism decides what information about the object to actually log.
The way you have done it defeats that idea.
为了正确记录，您需要的不仅仅是一些字符串。日期、来源、类别等，您可能希望以更结构化的方式存储。
总而言之，在 String 上创建日志扩展方法感觉完全是错误的。扩展方法的功能应该与其所操作的类型有相当强的关联，符合单一责任原则。在你所描述的情况下，这显然被违反了。
For proper logging, you would want far more than just some string. Date, source, category etc., which you may want to store in a more structured manner.
All in all, creating a logging extension method on String feels just plain wrong. The extension method's functionality should have a fairly strong association with the type it's operating upon, in line with the single responsibility principle. In the case as you described, that's clearly being violated.
这种方法的最大问题是几乎不可能非常干净地将依赖项注入静态/扩展方法。这意味着您的日志记录解决方案（假设它比将内容转储到标准输出/控制台/调试更加复杂）必须启动并配置为对项目进行任何类型的测试。曾经。
The biggest problem in this approach is it is nearly impossible to inject dependencies into static/extension methods very cleanly. Meaning your logging solution (presuming it is to become more complex than dumping things to stdout/console/debug) has to be spun up and configured to do just about any sort of testing on the project. Ever.