Wymaganie implementacji interfejsu do statycznej metody analizy składni

Question

Mam minimalny interfejs i będę miał do czynienia z kolekcją obiektów, których klasy implementują ten interfejs. Kolekcja (wraz z powiązaną z nią funkcjonalnością) nie przejmuje się żadnymi szczegółami tych obiektów poza ich nazwą, możliwością ich konwersji do formatu XML i możliwością analizowania ich z XML.

Przyszłe implementacje interfejsu znacznie poprawią elementy kolekcji i oczywiście zaimplementują własne metody Parse i ToXml (które będą używane przez kolekcję do odpowiedniego analizowania tych elementów po napotkaniu).

Niestety, nie mogę wyświetlić statycznej metody analizy w interfejsie (przeczytałem thesethreequestions). Nie ma sensu, aby metoda Parse wymagała instancji. Czy jest jakiś sposób, aby wymagać, aby wszystkie implementacje interfejsu miały metodę statycznej analizy parse?

public interface IFoo 
{ 
    string Name { get; } 

    string ToXml(); 

    static IFoo Parse(string xml); // Not allowed - any alternatives? 
} 

Answer 1

Nie możesz tego zrobić. A statyczne metody i tak nie są polimorficzne, więc nie miałoby to zbytniego sensu.

To, czego chcesz, to jakiś wzór fabryczny.

Answer 2

Jedyną alternatywą, która przychodzi mi do głowy jest użycie klasy abstrakcyjnej zamiast interfejsu tutaj. Jednak nie będziesz w stanie przesłonić zachowania metody statycznej w klasach potomnych.

można osiągnąć nieco podobne zachowanie przy użyciu wzorca Factory i wymagające zajęcia wykonawczych IFoo mieć odniesienie do tej fabryki (który może być wstrzykiwany w nich poprzez wstrzyknięcie konstruktora):

public interface IFoo 
{ 
    string Name { get; } 

    string ToXml(); 

    IFooFactory FooFactory { get; } 
} 

public interface IFooFactory 
{ 
    IFoo Parse(string xml); 
} 

Answer 3

Zakładając Parse pobiera ciąg i zamienia ją w pełni zaludnionych obiektu, jak o metodzie Hydrate zamiast, jak:

interface IFoo { 
    string Name { get; set; } 
    int Age { get; set; } 
    void Hydrate(string xml); 
} 

class Foo : IFoo { 
    public string Name { get; set; } 
    public int Age { get; set; } 

    public void Hydrate(string xml) { 
     var xmlReader = ...etc...; 
     Name = xmlReader.Read(...whatever...); 
     ...etc...; 
     Age = xmlReader.Read(...whatever...); 
    } 
} 

void Main() { 
    IFoo f = new Foo(); 
    f.Hydrate(someXml); 
} 

Or Fluent go trochę:

public IFoo Hydrate(string xml) { 
    // do the same stuff 
    return this; 
} 

void Main() { 
    IFoo f = new Foo().Hydrate(someXml); 
} 

Answer 4

Może w ten sposób?

Nawet jeśli powyższe może być rozwiązaniem, zachęcam do skorzystania z fabryki abstact i/lub metody szablonów. Zobacz zamiast tego Template Method Pattern. Inną opcją może być użycie Extension method, jeśli nie chcesz go udostępnić w kilku implementacjach.

Answer 5

Najogólniej mówiąc, były znane (przy okazji), aby użyć metody rozszerzenie dla rzeczy tak:

public interface IFoo 
{ 
    string Name {get;} 
    string ToXml();  
} 

public class Foo : IFoo 
{ 
    public Foo(string name) 
    { 
     Name = name; 
    } 
    public string Name {get; private set;} 
    public string ToXml() 
    { 
     return "<derp/>"; 
    } 
} 

więc to instancja rzeczy, niech obsłużyć „statyczny” bit:

public static class FooExts 
{ 
    public static IFoo Parse(this string xml) 
    { 
     return new Foo("derp"); 
    } 
} 

a test:

void Main() 
{ 
    var aFoo = "some xml".Parse(); 
    Console.WriteLine(aFoo.ToXml()); 
} 

Jak wspomina @Jim, nie jest przypadek, w którym nie chcą się Foo plecach, w którym to przypadku można użyć coś takiego:

public static T Parse<T>(
    this string xml, 
    Func<string, IFoo> useMeUseMe = null) 
    where T:IFoo 
{ 
    if(useMeUseMe == null) 
     useMeUseMe = (x => new Foo(x)); 
    return (T)useMeUseMe("derp"); 
} 

niestety, musimy teraz powiedzieć metodę, co chcemy, kiedy odbiega od „normy”:

var aFoo = "some xml".Parse<Foo>(); 
Console.WriteLine(aFoo.ToXml());  
var aBar = "some xml".Parse<Bar>(s => new Bar(s)); 
Console.WriteLine(aBar.ToXml());  

Answer 6

Wyodrębniłbym wszystkie metody związane z serializacją do innego interfejsu. Rozważmy następujący przykład:

public interface IFoo 
{ 
    string Name { get; } 
    IFooSerializer GetSerializer(string format); 
} 

public enum FooSerializerFormat { Xml, Json }; 

public interface IFooSerializer 
{ 
    string Serialize(IFoo foo); 
    IFoo Deserialize(string xml); 
} 

public class Foo : IFoo 
{ 
    public string Name { get; } 

    public IFooSerializer GetSerializer(FooSerializerFormat format) 
    { 
     case FooSerializerFormat.Xml: 
      return new FooXmlSerializer(); 

     case FooSerializerFormat.Json: 
      return new FooJsonSerializer(); 
    } 
} 

public class FooXmlSerializer : IFooSerializer { /* Code omitted. */ } 
public class FooJsonSerializer : IFooSerializer { /* Code omitted. */ }