Best practice regarding interface implementation?

i have had cause declare number of interfaces , have found mnyself having think creatively 2 specific issues. example consider itranslatable interface.

interface itranslatable  {      // methods      string getculturalname(string locale = "");        // properties      string internalname { get; }      string locale { get; set; }      guid translationkey { get; set; }  }

now, applied many classes don't want provide base class implementation since many of implementors derived more important. instead use code snippets insert skeleton implementation (within own #region) , flesh out. , brings me 2 issues , me wondering if there better solution out there don't know about?

1. field declartions. is bad idea / reasonable / idea put field declarations fields exist support interface implementation  within #region interface implemented? or should field declarations molved top of class found people conventionally expect them be? can't put them in interface might feel belong!:-)

2. static support methods. example implementors of above itranslatable must provide a public static dictionary<guid,string> getvocabulary() returns internal strings class (ie possible instances) translation key (so centralized vocabulary manager can build full dictionary simple polling types implement itranslatable , invoking getvocabulary(). can't put a static method declaration in interface (a shame since existence of getvocabulary part of "contract" invoking should @ class level). @ moment put static declaration stub function code snippet nominal implementation. there better way establish "contract"?

note: experimented ivocabularyprovider interface achieves nothing directly because either getvocabulary() must static or have build collection class base entity implement vocabulary lookup (and getvocabulary instance method on that). ridiculous classes otherwise not require collections - impose expensive , unnecessary burden on implementors of such contract.

how others deal these issues? there best practice or go own way?

thanks in advance.

alistair

---

alistair

just responding first post (the second post tl;dr , don't understand gethashcode has original post)

1) what fields?  avoid defining own backing fields if @ possible (hooray automatic properties).  if must have backing field because property implementation funky absolutely should have declared before property.  code using field should property why force people go searching through code file?  have read "code complete" steve mcconnell?  if not, , read it.  sort of layout discussed in ch31 under "laying out data declarations" guiding principles laid out in ch 10 under 'keep variables "live" short time possible'.

you might want consider http://www.codeproject.com/articles/392516/why-i-use-explicit-interface-implementation-as-a-d once started following advice life got 7% better.

if implementations of interface similar enough have code snippet job consider creating single implementation , creating instance of implementation in classes need it.  of interface implementation wrappers single implementation.  if need change implementation once rather having track down places snippet used.

2) interfaces (and abstract classes) can't have static members.  there many discussions why case google reveal you.  bottom line, think want there no such thing static member of interface.

---

paul linton

Visual Studio Languages  ,  .NET Framework  >  Visual C#