Interface zwischen 2 Programmierern

[Gast]

Moin,

ich hab gerade gelesen, dass ein Interface hilfreich sein kann, wenn 2 oder mehrere Programmierer an einem Programm arbeiten.
diese 2 Programmierer machen sich Methoden aus und schreiben diese in ein Interface, danach kann jeder gegen das Interface programmieren,

so ganz kann das aber nicht stimmen:

angenommen ein Programmierer schreibt eine Verwaltung und der andere die Objekte, welche Verwaltet werden sollen

Verwaltung <-> Personen, Tiere

dann machen sich diese beiden ein Interface "Lebewesen" aus und der der die Verwaltung programmiert, programmiert gegen "Lebewesen", und der der die Klassen Personen und Menschen programmiert, programmiert ebenfalls gegen "Lebewesen".

Was ich jetzt nicht ganz verstehe ist, das der Programmierer, welcher die Verwaltung programmiert, ja auch was von den Klassen Personen und Tieren wissen muss, um diese zu instanzieren.

Was ist dann also der Vorteil eines Interfaces, außer das man die Personen und die Tiere in einer Collection "Lebewesen" verwalten kann.

Beste Grüße,

 

[diggaa1984]

wenn er sie instanziiert muss er wissen welche Lebewesen es gibt, korrekt, aber mehr auch nicht. Alles andere (Methodenaufrufe, etc.) wird über das Interface geregelt, das heisst er kann Personen wie Tiere über die selben Methodensignaturen bearbeiten und muss dazu nur wissen das es Lebewesen sind, und nicht ob da grad ne Person oder ein Tier vor ihm steht:

ArrayList<Lebewesen> lwl = new ArrayList<Lebewesen>();

lwl.add(new Person());
lwl.add(new Tier());

for (Lebewesen lw: lwl) {
   lw.setIrgendwas("Foo");
}

so in der Art ^^

 

[SlaterB]

Instanziieren ist immer der Feind aller Interface,
aber alles andere funktioniert

das Interface beschreibt, welche Methoden angeboten werden, vielleicht sowas wie gibAlter, gib Platzbedarf, gibPreis, gibHaltbarkeit usw,
nun kannst du in der Verwaltung die kompliziertesten Algorithmen nur Unternehmensoptimierung schreiben und dabei tausende Male gibPreis usw. aufrufen, ohne dass es entsprechende Klassen überhaupt geben muss,

das ganze ist natürlich nur ein theoretisches Gebilde, könntest es höchstens mit einer Dummy-Implementierung testen,
mit einer Methode
getPreis() {
return 5;
}

-------

die einzelnen Lebewesen oder vielleicht nur die genau eine implementierende Klasse können währendessen in aller Ruhe separat entwickelt werden,
mit tausenden Zeilen Quellcode zur sehr komplizierten Berechnung des Preises usw.

 

[ben200xx]

Hi,

der Verwalter muss nichts von Personen und Tieren wissen, da er ja nur mit dem Interface arbeitet.
D.h. das Inferface Lebewesen definiert z.B. die Methoden Atmen, Fortpflanzen.
Also Arbeitet der Verwalter nur mit den Methoden. Dass es sich z.B. um eine Klasse Person die Lebewesen implementiert und zusätzlich noch die Methode Sprechen implementiert, interessiert die Verwaltung nicht, da diese Methode nicht zum Interface Lebewesen gehört.

 

[Spacerat]

Relativ simpel: Die Aussage, das Der Programmierer der Verwaltung Kenntnis von den finalen Klassen (hier Personen und Tiere) des Interfaces (hier Lebewesen) haben muss, ist schlicht weg falsch. Die Verwaltung (ObjectStore) nimmt halt nur solche Objekte auf, die das Interface implementieren. Mal ein Beispiel mit einer typisierten ArrayList als Verwaltung. Dann sollte es Klar werden.

// das Interface
interface Lebewesen
{
    // Methoden deklarieren...
}

// Der Objekt-Programmierer
class Person implements Lebewesen
{
    // Methoden von Lebewesen implementieren
}

class Tier implements Lebewesen
{
    // Methoden von Lebewesen implementieren
}

Person friedl = new Person();
Tier kimba = new Tier();

// Die Verwaltung:
ArrayList<Lebewesen> store = new ArrayList<Lebewesen>();

store.add(kimba);
store.add(friedl);

mfg Spacerat

@Edit: Man seid ihr schnell... oder ich zu langsam... :-(

 

[e9926044]

aber so wie ich das verstehe, steht

Person friedl = new Person();
Tier kimba = new Tier();

in der Klasse Verwaltung und deshalb muss der Programmierer, der die Verwaltung programmiert,
Kenntnis über die konkreten Klassen haben muss,

lg

 

[Wildcard]

in der Klasse Verwaltung und deshalb meine ich auch, dass der Programmierer, der die Verwaltung programmiert,
Kenntnis über die konkreten Klassen haben muss,

Hängt davon ab was alles Teil dieser Verwaltung ist. Grob gesagt, der Autor der ArrayList kennt nicht alle Objekte die ich darin ablege.

 

[Spacerat]

aber so wie ich das verstehe, steht

Person friedl = new Person();
Tier kimba = new Tier();

in der Klasse Verwaltung und deshalb muss der Programmierer, der die Verwaltung programmiert,
Kenntnis über die konkreten Klassen haben muss,

lg

... und genau das ist ein Irrtum...

mfg Spacerat

 

[diggaa1984]

ich glaube das Wort Kenntnis wird hier überbewertet

Wenn ich Instanzen erstellen will, welche Personen oder Tiere sind, dann muss ich, egal wo ich diese Instanzen definiere, die nötigen Klassen kennen. "Kennen" im Sinne von "wissen wie sie heissen und wovon sie erben, oder was sie implementieren", mehr ist nicht notwendig. Kenntnis bezüglich Implementierung der vom Interface vorgeschriebenen Methoden ist nirgends notwendig, wenn ich gegen ein Interface programmiere (eventuell Angaben über Datenstrukturen, welche zur Realisierung des Problems genutzt wurden .. Bsp ArrayList vs. LinkedList oder so).

 

[didjitalist]

der ansatz ist eigentlich schon nicht mehr ganz korrekt. wenn der entwickler der verwaltung nicht bloß "Lebewesen", sondern auch "Hund" und "Katze" kennen muss, dann braucht man auch "Hund" und "Katze" als interface.

wenn er sich solche dinger auch noch erzeugen können soll, dann kann er ein weiteres interface nehmen, welches entsprechende "Lebewesen" erzeugen kann.

die notwendige infrastruktur müsste also ungefähr so aussehen

interface Lebewesen
{
   int anzahlBeine();
}

interface Hund extends Lebewesen
{
  void machWau();
}

interface Katze extends Lebewesen
{
  void machMiau();
}

interface Zeuger
{
  Hund zeugeHund();
  Katze zeugeKatze();
}

 

[slawaweis]

Was ist dann also der Vorteil eines Interfaces, außer das man die Personen und die Tiere in einer Collection "Lebewesen" verwalten kann.

der Vorteil eines Interfaces in diesem Fall ist die Abstraktion der Funktionen/Eigenschaften einer Klasse (oder der Aufgabe, falls die finale Lösung aus mehreren Klassen besteht). Die konkrete Klasse muss dabei nicht mal existieren oder es gibt mehrere equivalente Implementierungen.

Interfaces sind ein gutes Mittel um die Arbeit im Team gut zu verteilen. Doch dazu gehört normalerweise mehr. Erst mal muss man gute Interfaces erstellen, damit später weniger nachgebessert werden muss. Auch sollte man klären, wie man später die Erweiterung des Interfaces organisiert. Da gibt es die Möglichkeit einfach das Interface zu erweitern und dann sollen alle ihre Programmteile aktualisieren oder man bedient sich der unschönen Lösung mit "interface Lebewesen2 extends Lebewesen".

Zweitens sollte man klären, wie die einzelnen Programmteile bis zu der Verschmelzung getestet werden. Wenn für die Tests keine Instanzen einer konkreten Implementierung benötigt werden, dann hat man im Grunde auch keine Probleme. Wenn man jedoch an lebendigen Objekten testen will, muss man in der Designphase mit den Interfaces auch gleich die Dummy Klassen vereinbaren, also z.B. "LebewesenDummy". Diese enthalten die minimalste Lösung zu einem Interface in Form einer instanzierbaren Klasse.

Drittens, erstellt sich jede Teilgruppe im Team Factory-Methoden (nach dem Factory-Pattern), um die Testobjekte auf einfache Art zu bekommen. Das wäre z.B. so was:

public class LebewesenFactory
{
 public static Lebewesen createLebewesen()
  {
  return new LebewesenDummy();
  }

 public static Lebewesen createLebewesen(Object param1, Object param2, Object param3)
  {
  Lebewesen l = new LebewesenDummy();
  l.setParam1(param1);
  l.setParam2(param2);
  l.setParam3(param3);
  return l;
  }

 public static Lebewesen createLebewesen(String type)
  {
  if(type.equals("Tier"))
    return new LebewesenDummy("Tier");
  else if(type.equals("Mensch"))
    return new LebewesenDummy("Mensch");
  else
    return new LebewesenDummy("Alien");
  }
}

// ...

ArrayList<Lebewesen> list = new ArrayList<Lebewesen>();

list.add(LebewesenFactory.createLebewesen());
list.add(LebewesenFactory.createLebewesen(1, 2, 3));
list.add(LebewesenFactory.createLebewesen("Tier"));
list.add(LebewesenFactory.createLebewesen("Mensch"));
list.add(LebewesenFactory.createLebewesen("C# Programmierer"));

Jetzt kann man sich ganz bequem Testobjekte mit LebewesenFactory.createLebewesen(...) erstellen. Wenn dann die richtige Implementierung von Lebewesen zu Verfügung steht, müssen nur die Methoden in der LebewesenFactory verändert werden und es kann sofort getestet werden. Weiterhin hat die Factory den Vorteil, dass man so auf einfache Weise mehrere Implementierungen von Lebewesen austesten kann, falls z.B. 2 verschiedene Teilgruppen an verschiedenen Umsetzungen gearbeitet haben oder es inzwischen eine Version 2 gibt.

Falls dann irgendwann mal alles gründlich ausgetestet ist und die LebewesenFactory nicht mehr gebracht wird, kann man über Refactoring oder einfach Find/Replace die Factory Aufrufe in direkte Instanziierungen umwandeln. Allerdings, falls man das Factory-Pattern mal gründlich verstanden hat, arbeitet man eher damit, als mit "new"

Slawa