I am currently in the process of trying to master C#, so I am reading Adaptive Code via C# by Gary McLean Hall.
He writes about patterns and anti-patterns. In the implementations versus interfaces part he writes the following:
Developers who are new to the concept of programming to interfaces often have difficulty letting go of what is behind the interface.
At compile time, any client of an interface should have no idea which implementation of the interface it is using. Such knowledge can lead to incorrect assumptions that couple the client to a specific implementation of the interface.
Imagine the common example in which a class needs to save a record in persistent storage. To do so, it rightly delegates to an interface, which hides the details of the persistent storage mechanism used. However, it would not be right to make any assumptions about which implementation of the interface is being used at run time. For example, casting the interface reference to any implementation is always a bad idea.
It might be the language barrier, or my lack of experience, but I don't quite understand what that means. Here is what I understand:
I have a free time fun project to practice C#. There I have a class:
public class SomeClass...
This class is used in a lot of places. While learning C#, I read that it is better to abstract with an interface, so I made the following
public interface ISomeClass <- Here I made a "contract" of all the public methods and properties SomeClass needs to have.
public class SomeClass : ISomeClass <- Same as before. All implementation here.
So I went into all some class references and replaced them with ISomeClass.
Except in the construction, where I wrote:
ISomeClass myClass = new SomeClass();
Am I understanding correctly that this is wrong? If yes, why so, and what should I do instead?