Objektrückgabe durch Factory-Methode in abstrakten Klassen

[stern-wf]

Ich bin dabei mich auf Java einzulassen (ansonsten reichte mir C++), doch die Sache (der Sinn!?) mit diesen 'Interfaces' ist mir noch unklar,
ganz abgesehen von der Design-Pattern-Thematik :autsch:
(Ppuuuuh, warum einfach, wenn's auch kompliziert geht)....


Nun meine Frage:

Interfaces und Abstrakte Klassen sind ganz nützlich, um Clienten dazu zu zwingen Methoden zu implementieren.
In dem Buch "Effektiv Java prog..." :###
heißt es, man solle statische Factory-Methoden statt Konstruktoren verwenden.

Doch wie sage ich entweder

- einer abstrakten Basisklasse, dass die statische "GetInstance"-Methode ein Object, der jeweils
abgeleiteten Klasse zurückgeben soll ???:L ?

oder wie

- schreibe ich ein Interface/Abstrakte Klasse, welches dem Clienten vorschreibt, er müsse noch
die statische "GetInstance"-Methode implementieren oder überschreiben ???:L ?

Beispiel:

public interface IModel {
    public int getIntField();
    public void modify(int value);
}

public abstract class AbstractModel implements IModel {
    private int intField = 0;
    public int getIntField() { return intField; }

    public void modify(int value) {
        if (value <= Integer.MAX_VALUE && value >= Integer.MIN_VALUE)
            this.intField += value;
    }
    public static Object getInstance() { return null; }
}

public class ConcreteModel extends AbstractModel
{
    private ConcreteModel() {}
    public static Object getInstance() { return new ConcreteModel(); }
}

public class UiTest01
{
    private UiTest01() {}

    public static void main(String[] args) {
      UiTest01   App  = new UiTest01();

      ConcreteModel  Data = (ConcreteModel) ConcreteModel.getInstance();
      ConcreteView   UserInterface = (ConcreteView) ConcreteView.getInstance();

      if (!UserInterface.init( Data ))
          System.out.println("Fehler in Klasse \"View\"!");
      else UserInterface.update();
    }
}

Wenn hierbei z.B. vergessen wird, in 'ConcreteModel' die getInstance() der Basisklasse zu überschreiben,
dann wird natürlich 'null' geliefert, was ja nicht gerade erwünscht ist.

Abstrakte Basisklasse sind doch eigendlich ideal, um die globalen, statischen Klassenmethoden aufzunehmen,
so klappt das aber irgendwie nicht (Objekt-Rückgabe??)...

...hat da irgendjemand eine ELEGANTE & professionelle Lösung :bahnhof: ??

MfG
stern-wf

 

[Beni]

Also der Sinn dieser Sache:

heißt es, man solle statische Factory-Methoden statt Konstruktoren verwenden

verstehe ich auch nicht ganz. Habs noch nie so gemacht, und bin eigentlich ganz gut zurechtgekommen. :bae:

Wenn hierbei z.B. vergessen wird, in 'ConcreteModel' die getInstance() der Basisklasse zu überschreiben,
dann wird natürlich 'null' geliefert, was ja nicht gerade erwünscht ist.

Also, ich glaub nicht, dass das so je funktionieren wird. Eine static-Methode kann man nicht überschreiben...

Vielleicht würde sowas funktionieren:

public interface XYZModel{
  public XYZ create();
}

public class XYZ{
  private XYZModel xyzModel;

  public static XYZ getInstance(){
    return xyzModel.create();
  }

  public static void setXYZModel( XYZModel model ){
    xyzModel = model;
  }
}

Und dann kann man dem XYZ alles mögliche unterjubeln.
Aber mir fällt kein Beispiel ein, wo das wirklich sinnvoll wäre. Da gibt man besser einer bestimmten Methode das XYZModel, und kann so genau bestimmen, wo welche Implementation von XYZ hingehört. (Ich war noch nie Fan von static, verursacht im Endeffekt mehr Probleme als es löst).

Wie gesagt, was das Buch hier will, verstehe ich nicht ganz. Vielleicht muss man den Zusammenhang kennen, wenn es einen Link dazu gibt, ich wäre interessiert.

Ich glaub die beste Verwendung von Interfaces sieht man immer noch beim ActionListener und beim TableModel. (kannst ja mal in der API gucken).

mfg Beni

 

[stern-wf]

Danke für die Antwort.

Im Buch (ISBN 3-8273-2131-X) wird damit argumentiert, dass
statische Factory-Methoden folgende Vorteile haben
(gegenüber einfachen Konstruktoren):

Punkt 1) Der Code soll leichter lesbarer werden, weil sie eindeutige Namen haben

Punkt 2) Die verpflichtende Parameter-Reihenfolge bei Konstruktoren entfällt

Punkt 3) Instanzen könnten bei Erzeugung gecacht werden
und ggf. wiederholt ausgegeben werden.

Punkt 4) Die Factory-Methode kann ggf. auch Objekt der Untertyps zurückliefern,
was flexibel ist (z.B. bei Dienstanbieterarchitekturen).

Naja, letztendlich kommt er dann zum Schluß, dass beide (Fact.methoden und Konstr.)
ihre Stärken haben, aber mich überzeugte Punkt 1.

Ich teste mal Deinen Ansatz...

MfG
Thomas

 

[Beni]

Naja, Punkt 1. ist für mich gerade der schlechteste. Soooo schlimm ist der Syntax für Konstruktoren ja wirklich nicht :wink:

Punkt 2. verstehe ich nicht ganz, aber hört sich auch nicht dolle an. Man kann auch mit Konstruktoren die Parameterreihenfolge verändern.

Punkt 3. ist sicher der wichtigste, und der überzeugendste.

Punkt 4. schon, aber das kann Auswirkungen auf das gesammte Programm haben. Und daher kann der Schuss auch nach hinten losgehen.

Naja, meine Ablehnung ist wohl offensichtlich :wink: so hat eben jeder Codder seine eigene Philosophie die er verteidigen will.

Gruss Beni

 

[Shorty76]

Ich nehme mal an, daß es um das Factory Pattern geht - kleines Beispiel:

public class XYZFactory
{
  private static XYZFactory instance = null;
  private XYZ product = null;
  private String XYZClass = null; // wird dynamisch konfiguriert z.B. mit System.getProperty("PRODUCT")

  private XYZFactory() throws Exception
  {
    this.product = this.getProduct();
  }

  public static XYZFactory getInstance()
  {
    if (instance == null)
    {
      instance = new XYZFactory();
    }
    return instance;
  }

  private XYZ getProduct() throws Exception
  {
    Class clazz = null;
    XYZ retVal = null;
    try
    {
      clazz = Class.forName(this.XYZClass);
      retVal = (XYZ) clazz.newInstance();
    }
    catch (Exception e)
    {
      throw new Exception("Could not create XYZ: " + this.XYZClass + "Reason: " + e.toString());
    }
    return retVal;
  }

  public XYZ createXYZ()
  {
    return this.product;
  }
}

Hierbei geht es darum den Code für die Instanzierung (von Klassen, welche ein Interface XYZ implementieren) auszulagern. Ein Client könnte XYZ folgendermaßen erzeugen:

XYZFactory factory = new XYZFactory();
XYZ myXYZ = factory.createXYZ();

Durch die Kapselung des Erzeugungsprozesses weiß der Client nicht, mit welcher Implementierung gearbeitet wird.

N.B. eine Factory wird meist als Singelton(wie im Beispiel) imlementiert ...