DirectX interfaces

They're inherited/implemented internally somewhere else (e.g. Inside d3d11.dll). You're not supposed to inherit/implement them, because you're a client of the interface, not an author of the D3D runtime

The purpose of interfaces is to fully hide all implementation details from an object's client's (and sometimes also to enable polymorphism). In this case, we have no idea what the implementation of ID3D11Buffer looks like, because it's hidden behind the interface. This also allows MS to constantly change the implementation behind the scenes (with Windows update, or graphics drivers, etc) and our software doesn't care, because we talk to those different implementations via the interface.

13 hours ago, Hodgman said:

The purpose of interfaces is to fully hide all implementation details from an object's client's (and sometimes also to enable polymorphism).

Could you please explain this a bit further as I think I have not grasped it fully yet?
So by this you are saying we would use an interface for two possible scenarios. In one case to hide the implementation and to provide only the "public" interface and in other to use it for polymorphism. I always kinda connected the two concepts.

For DirectX part I guess they use the interfaces only for the first scenario, if I understood you correctly? Where in the second scenario we would create a class interface to be able to use a base pointer for inherited classes, for polymorphism.

The idea of information hiding via interfaces is a very general concept that exists far beyond the scope of OOP. It's a common recurring concept in almost every different software paradigm. It's a key technique to manage complexity of software, by reducing the number of moving parts to be considered at any one time...

Within OOP languages, there tends to be specific keywords that make creation of "interfaces" (the general idea) easy -- e.g. in C# the "interface" keyword, or in C++ the "class" and "virtual" keywords.

Within OOD, there's a lot of thought given to how interfaces (the general idea, not the language-specific features) should be used in your software architecture. e.g. "smaller interfaces are better than big ones", or "Decouple modules by creating interfaces that sit in between them", or "If using polymorphic interfaces, implementations must always behave according to the base interface", or "Try to make interfaces that aren't going to need to be changed by future programmers, and then put the bits that will change over time inside the implementations of those interfaces"... You could use these bits of advice in any language -- even ones that don't have a "class" or an "interface" keyword. e.g. in C libraries, it's common to write something that embodies the idea of an interface by using function pointers.

2 hours ago, ryt said:

For DirectX part I guess they use the interfaces only for the first scenario, if I understood you correctly? Where in the second scenario we would create a class interface to be able to use a base pointer for inherited classes, for polymorphism.

They use it for polymorphism too -- e.g. ID3D11Resource is a polymorphic interface (ID3D11Buffer is a ID3D11Resource).

When you call CreateTexture2D/etc, internally, it might have some internal class that's called something like CTex2D, which implements ID3D11Texture2D, for all we know... but that's hidden from us. All we know is that it creates some kind of object that implements the ID3D11Texture2D interface, and we can use this interface to talk to the object.

2 hours ago, ryt said:

So by this you are saying we would use an interface for two possible scenarios. In one case to hide the implementation and to provide only the "public" interface and in other to use it for polymorphism. I always kinda connected the two concepts.

Yep. For an example of the first concept -- non polymorphic interfaces, look at PIMPL (aka Opaque pointers).