Update AV1125: Don't expose stateful objects through static members (#353)

Author: dennisdoomen

_rules/1125.md

@@ -1,9 +1,11 @@
 ---
 rule_id: 1125
 rule_category: member-design
-title: Don't expose stateful objects through static members
+title: Don't hide dependencies behind static members
 severity: 2
 ---
-A stateful object is an object that contains many properties and lots of behavior behind it. If you expose such an object through a static property or method of some other object, it will be very difficult to refactor or unit test a class that relies on such a stateful object. In general, introducing a construct like that is a great example of violating many of the guidelines of this chapter.
+A well-known example is `HttpContext.Current` from classic ASP.NET. But modern .NET still has plenty of cases where static members expose global or environment-dependent state, such as `Environment.MachineName`, `DateTime.UtcNow`, `Environment.GetEnvironmentVariable`, and `File.Exists`. These are problematic because:
+- They hide implicit dependencies, making code harder to understand.
+- They make unit testing difficult, especially running tests in parallel.
 
-A classic example of this is the `HttpContext.Current` property, part of ASP.NET. Many see the `HttpContext` class as a source of a lot of ugly code. 
+Instead, make dependencies explicit by injecting them through a constructor or method parameter, or by injecting an abstraction (e.g., `TimeProvider` instead of calling `DateTime.UtcNow` directly).