Does implicit and explicit cast operator overloading violate the D in SOLID principles of OO?

Question

I'm looking at different patterns and techniques for implementing logic to convert object from one class to another, and the most elegant seems to be explicit cast operator overloading (in C#). However, it seems to me that it violates the Dependency Inversion principle, as it requires one concrete class to have references to another concrete class.

Is this assessment accurate? Is it problematic? Is there a way to implement explicit cast operator overloading without violating the DI principle?

public class Model
{
    public string Prop1 { get; set; }
    public string Prop2 { get; set; }
}

public class ViewModel
{
    public string PropOne { get; set; }

    public static explicit operator ViewModel(Model model)
    {
        // Conversion logic that references both classes
    }
}

public class Program
{
    public void Main()
    {
        var model = new Model{ Prop1 = "SomeValue", Prop2 = "SomeOtherValue" };
        var viewModel = (ViewModel) model;

        Console.WriteLine(viewModel.PropOne); // Outputs "SomeValue" to the console
        Console.ReadKey();
    }
}

Answer 1

No matter what, you're going to have references to the other class if you want to convert between them - you either have your class know about the class you need to convert itself into, or you put a constructor on the other class which means it has to know about your class (or has to accept a heap of property parameters that just happen to match the individual properties of your class which will just be very ugly)

You could create a "factory" class that exists solely to turn objects of one class into another, but I'd say that was just getting silly. It also would need to know about both classes but at least each of those classes could exist in their own isolated bubbles. This maybe very important or useful in some circumstances.

But the general case, no matter what, you have to interact with the rest of the world so there will always be interface points you ave to deal with.