Ordering of static fields in C# matters

via Ordering of static fields in C# matters

The ordering of static fields does matter.
But per your examples, here is the pattern I always use:

public class Person
{
    private static EmptyPerson _emptyPerson;
    public static Person Empty => _emptyPerson ?? ( _emptyPerson = new EmptyPerson() );
}

The allows the Empty value to be initialized once and read-only, yet still used many times.
It also hides away the requirements of the initialization (the value pulled from a database for example) from the public getter. We could even put the value into a Lazy<Person>().

And in C# 8.0 we now have the compound assignment!

public class Person
{
    private static EmptyPerson _emptyPerson;
    public static Person Empty => _emptyPerson ??= new EmptyPerson();
}

 

Advertisements
Posted in C#

C# Dependency Injection via /r/csharp

via Trying to understand something about Dependency Injection : csharp

User badlife says this:

DI is a lot deeper than you’re thinking. It’s an entirely different way of doing architecture. Here’s a simple example:

Without DI:

  • I’m a component. I need X to do some work. So I’ll create an instance of X and use it. I don’t want Y, or something that looks like X but behaves differently– I want an instance of X and only X.

With DI:

  • I’m a component. I need an instance of X to do some work
    • I’m not going to create an instance of X– I’ll let you give me one when you create me
    • I don’t care if X is really X, as long as it looks like X.
    • I don’t want Y, but if Y pretends to be X, I’ll never know. This is because I only want something that lookslike X.

Here’s an example in concrete terms:

  • The ‘component’ is something that does a calculation. As part of the calculation, it needs to call a web service to get a value (let’s say an interest rate)
  • X is usually a component that calls a web service to get the interest rate
  • Y is a testing component that just returns ‘1.0’ for the interest rate

Without DI, the component is very hard to test because it needs to call a ‘live’ web service to get an interest rate. What if that web service isn’t live? What if it isn’t accessible from the testing environment? The test could be running as part of a build, and the build server might not be able to see the web service.

With DI, both X and Y can implement a common interface. The component doesn’t actually create an instance of X– it just asks for a reference to the interface. So in a real world scenario, the system gives the component a ‘real’ instance of X by passing a reference to its interface. In a testing scenario, the system gives the component a ‘fake’ version of X (it’s actually Y!) also by passing a reference to its interface. The component doesn’t know or care about the internal implementation of what it thinks is X, and can do its work without the web service being available.