Java dynamisch Objekt erschaffen

[hendr1k1]

Ich will ein Objekt abhängig von einigen Werten erzeugen:

if ( Bedingung1 ){
Foo bar = new Foo();
}else {
Qux bar = new Qux();
}

In NetBeans will das so nicht laufen, da er meint, dass bar nicht existiert.

Wie kann ich das Problem lösen?

 

[Yuuri]

bar ist nur innerhalb des jeweiligen Blocks gültig. Du müsstest bar also vor der Bedingung definieren. Du kannst es dann allerdings nicht variabel zuweisen. Kenn mich mit Java nicht wirklich aus, von daher kann ich dir ab hier nicht wirklich weiterhelfen.

 

[hendr1k1]

Das habe ich probiert. Aber wenn ich vorher einfach ein Objekt erschaffe, dann kann ich es später nicht mehr einfach "überschreiben".

 

[NullPointer]

Laß mich raten: Netbeans (bzw. der Java-Compiler) meckert nicht bei der Erzeugung des Objekts, sondern weiter unten, wenn du es benutzen willst?

Das liegt daran, daß der sog. Scope der Variable - also der Bereich des Codes, in dem sie "lebt" und verwendet werden kann - auf den Block beschränkt ist, in dem du sie deklarierst. Will sagen: Außerhalb des if-Blocks bzw. des else-Blocks ist bar nicht zu sehen.

Du mußt also bar vorher deklarieren - und das wiederum bedeutet, daß du es nicht als Foo bzw. Qux deklarieren kannst, sondern eine gemeinsame Oberklasse (bzw, ein gemeinsames Interface) als Typ wählen mußt. Ich nehme mal an, daß so eine Klasse/Interface existiert - wenn nicht, dann solltest du das wohl anders lösen.

Edit: Da war ich noch am Schreiben, als die Antworten reinkamen. Was meinst du mit "überschreiben"?

 

[BlackSheep]

Object bar = null;

if (Bedingung1) {
     bar = (Foo) new Foo();
} else {
     bar = (Qxu) new QxU();
}

bar einfach als Object definieren, sollte funktionieren.
Habs schnell getestet mit Integer und String, da hats funktioniert

 

[hendr1k1]

Beispiel aus Ruby:

bar = Foo::new

bar = Qux::new


Das ist zwar echt mießer code, dient aber nur als Beispiel.


Ja du hast recht, NB meckert weiter unten außerhalb des Blocks. Dann werd ich mir mal eine Lösung ausdenken müssen...

 

[NullPointer]

Die Lösung von BlackSheep ginge, aber wenn du keine "bessere" Elternklasse findest als Object, dann solltest du es bleiben lassen. Es sollte auf jeden Fall eine Klasse (oder ein Interface) sein, das alle Methoden bereitstellt, die du auf bar aufrufen willst. Ansonsten müßtest du bei diesen Aufrufen immer vorher wieder prüfen, ob bar nun ein Foo oder ein Qux ist. Das wäre aber ausgesprochen unschön und gar keine gute OOP - in diesem Fall solltest du die beiden Codeteile für Foo und Qux dann komplett trennen.

 

[Fonce]

Also wenn das erzeugte Objekt abhändig von einer Bedingung ist, dann gehe ich mal davon aus das die beiden Klassen eine gewisse Ähnlichkeit haben werden oder?

 

[NullPointer]

Ich hoffe es In aller Regel sollte es tatsächlich so sein, ja, aber man kann ja nie wissen ^^

 

[Fonce]

Ja weil wenn das nämlich wirklich der Fall wäre, dann sollte man sich lieber noch mal überlegen ob man OOP richtig angewendet hat^^
Das ganze wäre dann nämlich mit einem Interface und zwei verschiedenen Klassen Implementierungen sehr leicht zu realisieren
Dann brauch ich nämlich nur noch ein Object des Interface anlegen und dann je nach Bedingung das Object mit den Implementierungen erzeugen

FooInterface test;

if(true){
  test = new Foo();
} else {
   test = new Qux();
}

 

[lbm1305]

Keine Ahnung ob das in Java möglich ist, aber im .NET wäre dies eine Möglichkeit:

        public T GetInstance<T>()
        {
            return (T) Activator.CreateInstance(typeof (T));
        }

Im Einsatz: (Hier PseudoCode)
var foo = GetInstance<Foo>(); // foo ist vom Typ Foo

 

[toeffi]

Keine Ahnung ob das in Java möglich ist, aber im .NET wäre dies eine Möglichkeit:

        public T GetInstance<T>()
        {
            return (T) Activator.CreateInstance(typeof (T));
        }

Im Einsatz: (Hier PseudoCode)
var foo = GetInstance<Foo>(); // foo ist vom Typ Foo

Ahh Schlechte Idee. Dafür müsste T : new() unterstützen, mach das auf ner Klasse die nen protected oder gar keinen Ctor hat und du kriegst Probleme Zumal Reflection nicht immer das mittel zur Wahl ist, wenn man es übers Objektmodell abbilden kann.

 

[Fonce]

@lbm1305
Dein Beispiel ist ein Beispiel für Generics wenn ich das richtig sehe(Nur ein Tipp, das hat außerdem eher was mit der Sprache zu tun und .Net ist keine Psrache sondern ein Framework )

Ich meine aber Interfaces diese sehen z.B. in C# so aus
http://msdn.microsoft.com/en-us/library/ms173156.aspx

In Java sieht das ganze so aus
http://www.programmersbase.net/Content/Java/Content/Tutorial/Java/Interface.htm

 

[1668mib]

Naja, sollten die Klassen wirkich unvereinbar sein, dann wäre das hier ne Möglichkeit

final Object bar;
if (...) {
  bar = new Bar();
} else {
  bar = new Qux();
}

...
if (bar instanceof Bar) {
  (Bar)bar.doSomething();
} else if (bar instanceof Foo) {
  (Qux)bar.doSomethingElse();
}

(Edit: Hat ja blacksheep auch schon mehr oder weniger so geschrieben)

@Fonce:
"hat außerdem eher was mit der Sprache zu tun und .Net ist keine Psrache sondern ein Framework"
Nun ja, wenn jemand sagt in .net geht das, dann soll das implizieren, dass es in C#, VB.NET, und sonst quasi allen Sprachen für .net so (bzw. analog) gehen sollte... man könnte ja die MSIL als ".net-Sprache" betrachten... außerdem könnte man im schlimmsten Fall in .net ja auch die Sprachen mischen...

Und Interfaces sind schön und gut, wenn man die Klassen selbst anpassen kann und vor allem, wenn sie auch einen "Zusammenhang" haben...

 

[Fonce]

Es ist aber trotzdem falsch zu sagen das es bei .Net so geht, den .Net ist nun mal keine Sprache! Der Begriff wird von vielen einfach im falschen Kontext benutzt...

 

[1668mib]

Dann solltest du es besser machen und .net (so schreibt man das übrigens, wenn wir schon von richtig und falsch sprechen) als Plattform bezeichnen und nicht als Framework.

Und wir sollten alle aufhören zu sagen, dass die Sonne auf- oder untergeht. Das ist faktisch falsch. Außerdem scheint die Sonne jeden Tag in etwa gleich, ich weiß jetzt nicht wie groß der Einfluss von Sonnenflecken dabei ist... es ist einfach nicht korrekt... klar, jeder weiß was man damit meint, aber wir müssen dabei einfach des Prinzips wegen korrekt sein.

Edit:
Gut, Framework und Plattform scheinen in einigen Dingen gleichbedeutend verwendet zu werden, aber ich kann mich irgendwie nicht anfreunden Java als Framework zu bezeichnen, das ist für mich eine Plattform (und eine Sprache, und eine Insel, ...)

 

[Fonce]

Mh... also MS schreibt es .NET...und mh... sie bezeichnen es als Framework....
http://www.microsoft.com/net/

Aber bitte, wenn du meinst....

EDIT:
Java ist auch erstmal nur eine Sprache und nichts weiter. Und den Code dann ausführen zu können benötigt man eine Laufzeitumgebung welche dann meist in einer Plattform eingebettet ist.

.Net ist ein Framework, da es sehr viele zusätzliche Bibliotheken mitbringt und zum Beispiel für Windows Forms und WPF usw.

Ein Framework in der Java Welt wäre z.B. Swing

 

[1668mib]

Das .net-Framework sehe ich eigentlich als Teil der .net-Plattfom. Aber Plattform und Framework sind wie mein Edit noch ergänzt hat fließend...

und ja, Microsoft hat die Schreibweise geändert... früher zu Release war es .net (zu der Zeit als es auch noch Office .net geben sollte oder wie das heißen sollte, also als MS wohl selbst noch nicht genau wusste, wo .NET hingeht...), jetzt .NET, ich tu mich mit dem Umgewöhnen da noch schwer...

 

[carom]

Wenn du was lernen willst, Threadstarter.

http://en.wikipedia.org/wiki/Factory_method_pattern

 

[lynxx]

Interface erscheint mir auch am sinnvollsten, alternativ eine gemeinsame Mutterklasse, z.B:

public class Vehicle {
  int maxkmh;
  String name;
  public Vehicle(String name, int maxkmh) {
    this.name = name;
    this.maxkmh = maxkmh;
  }
  ...
}

public class Car extends Vehicle {
    ...
  public Car(String name, maxkmh,...) {
    super(name, maxkmh);
    ...
  }
    ...
}

public class Motorbike extends Vehicle {
    ...
  public Motorbike (String name, maxkmh,...) {
    super(name, maxkmh);
    ...
  }
    ...
}


Vehicle bar;
if (...) {
  bar = (Vehicle)new Car(...);
} else {
  bar = (Vehicle)new Motorbike(...);
}