3

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();
    }
}
  • 1
    Can you explain why it's the most elegant approach? Can you also give an example of this in code? – MetaFight Sep 29 '15 at 14:21
  • By "most elegant" I simply mean that, once implemented, it allows for the most terse and natural (in C# terms) syntax. I'll add a code example shortly. – Daniel Arant Sep 29 '15 at 14:22
  • 1
    Why not just a constructor on ViewModel that takes a Model? The explicit cast operator is NOT natural for C#. – Sign Sep 29 '15 at 14:34
  • 1
    That is one option I have used in the past, but it raises the same question regarding the principle of DI as it requires the ViewModel to reference the concrete Model class. In what sense is the explicit cast operator unnatural? – Daniel Arant Sep 29 '15 at 14:37
  • 1
    Interfaces make operators second class citizens. – Wilbert Sep 29 '15 at 14:45
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.