C# Proper solution needed for "can't specify constructor/static method in interface" problem
<p>Okay, I need some help here.</p>

<p>This is the same old <strong>"can't use an interface to enforce constructors/static methods"</strong> problem.</p>

<p><strong>WHAT IS THE PROPER OO DESIGN THEN??</strong></p>

<p>I have a set of data entities (Entity Framework stuff) for which I wrote partial class methods to convert to/from XML (XElement objects).</p>

<p>I have an instance method to "save" XML:</p>

<pre><code>// Convert entity to XML
public XElement ToXml() {}
</code></pre>

<p>...and I have a constructor to "read" XML:</p>

<pre><code>// Create entity from XML constructor.
public MyEntity(XElement) {}
</code></pre>

<p>Alternatively, I could use a static factory method to "read" XML:</p>

<pre><code>public static MyEntity ParseXml(XElement) {}
</code></pre>

<p><strong>The dilemma:</strong></p>

<ol>
<li><p>I could create an interface that mandates the "save" <code>ToXml()</code> method, but what good is that if it only addresses half the problem? An interface can't enforce either of the "load" methods.</p></li>
<li><p>I could rely on my own good intent to create these methods without any sort of contract.</p></li>
<li><p>I could create a static class filled with redundant methods like <code>XmlToEntity1()</code> and <code>XmlToEntity2()</code>, etc... (Now I've described a good 'generics' problem.) However, the specific conversion code (which is specific to each entity) would create separate methods or switch/case for each and seems to belong inside the entity classes, not in some other class, no?</p></li>
</ol>

<p><strong>If an experienced C# coder can show a good design for this common problem I think I would learn a lot from it.</strong></p>

<p>Happy 4th of July!</p>

<h1>Possible Solution 1</h1>

<p>A single <code>XmlSerializer</code> class with two static generic methods:</p>

<pre><code>public static T Deserialize&lt;T&gt;(XElement xml) {}
public static XElement Serialize&lt;T&gt;(T entity) {}
</code></pre>

<ul>
<li>Pro: Only one class (no interface needed)</li>
<li>Pro: Separates serialization responsibility from entity classes.</li>
<li>Con: Would still require separate methods or switch/case blocks for each entity type supported.</li>
<li>Con: ? Not extensible -- have to modify this class each time an entity changed or added/deleted.</li>
</ul>

<h1>Possible lessons learned?</h1>

<p>The "can't use interface for constructors and static methods" problem might be a symptom of:</p>

<ol>
<li>Violating the SRP (Single Responsibility Principal).</li>
<li>Violating the SoC (Separation of Concern) principal.</li>
</ol>
