Interface oder Klasse

[MathiasSimmack]

Der Luckie hat mich mit seiner Datenbank-Sache daran erinnert, dass ich auch selbst noch grübele, ob es in Ordnung ist, direkt mit Interfaces zu arbeiten (wie etwa IList in seinem Fall, oder IHxRegNamespace in meinem), oder ob man das besser in Klassen kapselt, die auf den Interfaces basieren.

Aber was ist dann mit solchen Interfaces, die selbst schon Methoden usw. enthalten? Speziell bei den Interfaces von Help 2.0 trifft das zu. Sobald ich bspw. eine Klasse auf der Grundlage von IHxRegNamespace entwerfe

Code:

public class Help2Namespace : IHxRegNamespace
{
   ...
}

dann meckert der Compiler, dass 3 Methoden des Interfaces nicht implementiert sind. Das weiß ich zwar, aber ich habe keine Ahnung, wie ich diese 3 Methoden unterbringen soll, zumal die eigentliche Funktionalität dort liegt. Ich weiß, dass ein Interface normalerweise dafür sorgt, dass sich eine Klasse an bestimmte Spielregeln hält und bspw. bestimmte festgelegte Methodennamen nutzt. Aber in meinem Fall handelt es sich um Interfaces, die auf Typbibliotheken aus der API-Welt zugreifen und die eigentliche Funktionalität enthalten.

So würde bspw. "IHxRegNamespace.Name" den Namen eines im System gefundenen Help 2.0-Namespaces zurückgeben. Aber wie soll man so was implementieren? Ich möchte keinen eigenen String definieren, sondern ich will ja exakt den vom Interface gefundenen Namen haben.


Weiß da wer Rat?

[S - tefano]

Also zumindest zu C# hat mir mal jemand gesagt, dass man ein solches Interface benutzen kann wie eine Klasse.
Beispielsweise

Delphi-Quellcode:

iInterface iInterfaceInstanz = new iInterface;
//und jetzt halt damit arbeiten:
String irgendwas = iInterfaceInstanz.StringAttribut;
int einErgebnis = iInterfaceInstanz.Aktion;

Aber ich weiß nicht ob das in Delphi auch geht... und ob ich mich richtig erinnere

[Frickeldrecktuxer_TM]

@S - tefano:
ja gilt auch für andere sprachen.

@MathiasSimmack:
willst du ein interface benutzen? dann siehe S - tefano's post.
willst du ein interface implementieren? dann musst du auch alle methoden implementieren die es deklariert. stell dir vor du würdest von einer rein abstrakten klasse ableiten. alle methoden (und properties) müssen implementiert werden. wie du sie implementierst ist dir überlassen.
ich weiß nicht, wo dein IHxRegNamespace interface vorkommt aber du solltest dich fragen ob du es selbst implementieren willst/sollst.

[Frickeldrecktuxer_TM]

halt! was S - tefano gepostet hat geht doch nicht in anderen sprachen. da wird ein interface instanziert. soweit ich weiß sollte das aber auch in c# nicht so gehen wie von dir gepostet.

[Elvis]

Man nehme folgende Interfaces:

Code:

interface IHxRegNamespace
{
   int Miep{get;}
}

interface IHxRegNamespaceFactoryDingsens 
{
  IHxRegNamespace GetNamespace();
}

Könnte man so verpacken:

Code:

public class Help2Namespace : IHxRegNamespace
{
   readonly IHxRegNamespace innerInstance;

   public int Miep
   {
     get{return innerInstance.Miep;
   }

  internal Help2Namespace(IHxRegNamespaceFactoryDingsens factoryDingsens)
  {
    this.innerInstance = factoryDingsens.GetNamespace();
  }
}

Aber benutzen? Wenn ich die Wahl habe baue ich APIs eigentlich immer interface basiert auf.
Mag daran liegen, dass ich sowas in Chrome schreibe, wo ich dank interface delegation fast multi inheritance habe und man ein wenig aspektorientiert vorgehen kann.
Aber selbst wenn ich eine interface basierte API bauen würde, ich würde diese ekligen COM Interfaces von HXS ganz sicher verpacken woll. *brr sich angewidert schüttelt*

[MathiasSimmack]

Ah ja, das ist doch ein netter Ansatz. Danke, Elvis. Im Prinzip kann ich also ein in der Klasse enthaltenes Interface nutzen und von dem die Daten abgreifen. Rein technisch könnte ich mir dann aber auch die Ableitung von IHxRegNamespace sparen, oder? Also einfach nur

Code:

public class Help2Namespace

anstelle von

Code:

public class Help2Namespace : IHxRegNamespace

denn das Interface würde in dem Fall "nur" dafür sorgen, dass meine Klasse die entsprechenden 3 Methoden (Name, GetProperty, IsTitle) enthält. Ich habe gerade mal ein wenig experimentiert:

Code:

public class Help2Namespace : IHxRegNamespace
{
   readonly IHxRegNamespace innerInstance;

   internal Help2Namespace(IHxRegNamespace factory)
   {
      this.innerInstance = factory;
   }

   public string Name
   {
      get { return this.innerInstance.Name; }
   }

   public bool IsTitle(string bstrTitle)
   {
      return this.innerInstance.IsTitle(bstrTitle);
   }

   public object GetProperty(HxRegNamespacePropId propid)
   {
      return this.innerInstance.GetProperty(propid);
   }

   // weitere Dinge, die man einbauen könnte ...
}
   
public class Help2Namespaces : CollectionBase
{
   public Help2Namespaces()
   {
      HxRegistryWalkerClass registryWalker = new HxRegistryWalkerClass();
      IHxRegNamespaceList namespaceList    = 
         registryWalker.get_RegisteredNamespaceList("");
      foreach (IHxRegNamespace helpNamespace in namespaceList)
      {
         this.Add(new Help2Namespace(helpNamespace));
      }
   }

   public Help2Namespace this[int index]
   {
      get { return ((Help2Namespace)(List[index])); }
      set { List[index] = value; }
   }

   public int Add(Help2Namespace help2Namespace)
   {
      return this.List.Add(help2Namespace);
   }

   // mehr ...
}

und wuppdi hat man alle vorhandenen Namespaces im Tree-View

Code:

Help2Namespaces help2Namespaces = new Help2Namespaces();
try
{
   foreach (Help2Namespace help2Namespace in help2Namespaces)
   {
      TreeNode treeNode = new TreeNode(help2Namespace.Name);
      treeView1.Nodes.Add(treeNode);
   }
}
catch (Exception ex)
{
   MessageBox.Show(ex.ToString());
}

Das geht sicher auch in ähnlicher Form, wenn man direkt auf die Interfaces zugreift, aber so wirkt es konsistenter.


@Frickeldrecktuxer_TM: Es geht ums Help 2.0-API, das eigentlich eine normale Win32-Bibliothek ist. Mit Hilfe des AxImp-Tools kannst du aus der Hauptbibliothek zwei .NET-Wrapper generieren, die ein paar Klassen und haufenweise Interfaces enthalten. Das Zeug verfolgt mich schon eine ganze Weile. Na ja, ich habe eben kein anderes Hobby...

[Frickeldrecktuxer_TM]

@MathiasSimmack: die dokumentation hätte mir schon gereicht.
oft sieht man in bibliotheken eine funktion die ein solches interface zurückliefert. das ist ein gutes zeichen dafür daß man dieses interface wahrscheinlich nicht selber implementieren will sondern es lediglich benutzen möchte also seine methoden aufrufen will.
das scheint bei dir der fall zu sein. du scheinst deine innerInstance woanders herzuholen und baust eine klasse drumrum, die ausschließlich die methoden des interfaces implementiert. dabei rufen sie jedoch nur die methoden der innerInstance auf. in deinem derzeitigen stand würde ich sagen daß du genauso gut auf deine eigene klasse verzichten könntest und gleich mit dem interface arbeiten könntest. ob du nun die methoden eines interfaces aufrufst oder die methoden einer klasse die wiederum die (gleichnamigen) methoden eines interfaces aufrufen dürfte egal sein. nur dein kommentar "// weitere Dinge, die man einbauen könnte ... " weist darauf hin daß es überhaupt sinnvoll ist eine eigene klasse zu schreiben.
ob es also sinnvoll ist deine interfaces nochmals zu kapseln hängt davon ab was du damit anstellen willst bzw. was du da zusätzlich noch dazupacken willst.

[MathiasSimmack]

Ich gebe zu, das Beispiel ist ein wenig zu simpel. Im realen Fall würde ich in der Help2Namespace-Klasse gleich noch die enthaltenen Hilfedokumente, Filter und Plug-ins integrieren, so dass ich das auch noch abfragen und/oder als Knoten in den Baum einhängen kann. Das wäre dann schon etwas, das man mit einer eigenen Klasse netter lösen kann. Zumindest sieht es .NETiger aus.
Ansonsten hast du vermutlich Recht. Ich kann auch ebenso die Funktionen, Methoden usw. der Interfaces direkt abgreifen. Nach dem Prinzip funktionieren ja auch meine bisherigen CSharp-Tools, die die Help 2.0 nutzen.

btw:

Zitat von Frickeldrecktuxer_TM:

@MathiasSimmack: die dokumentation hätte mir schon gereicht.

Es gibt keine Dokumentation zum Help 2.0-API. Mein Wissen basiert nur auf try'n'error.