Why classes tend to be defined as interface nowadays?

Question

These 2-3 last years, many projects I see, like Cuyahoga open source C# CMS, tends to define persistent and non persistent classes as Interface. Why? Is there a

Answer 1

At a really boring level interfaces can also help make for a faster compile.

public class A {
   B b;
}

public class B {
   public int getCount() {
       return 10;
   }
}

In this case every time internal changes to B are made, the compiler needs to re-evaluate A to determine if it needs to be recompiled.

Instead we use interfaces:

class A {
   IB b;
}

interface IB {
   int getCount();
}

class B : IB {
   public int getCount() {
       return 10;
   }
}

In this case A only depends on IB. No change to B requires any consideration of A at compile time.

At scale this effect on short circuiting dependency evaluation can significantly speed up compilation of large code bases. It is particularly powerful when there are a lot of classes depending on a single class that changes a lot.

Clearly this compile time benefit only works if the classes have no static dependency on the implementation classes. Doing the following would totally defeat this benefit:

class A {
    IB b = new B();
}

This is where Dependency Injection comes in. The DI container would construct a B and provide it to A as an IB so A doesn't need to have the static dependency.