Vererbung - Typabfrage

[tobbworld]

Hallo miteinander,

ich habe zur Zeit das Problem das ich gerne eine Fallunterscheidung für Betriebssysteme vornehmen möchte, sprich betriebssystemspezifische Eigenschaften setzen.

Vom logischen habe ich mir folgendes gedacht:

[highlight=Java]
Klasse OperationSystem
//beinhaltet Eigenschaften die alle BS gemeinsam haben



Klasse OperationSystemMac extends OperationSystem:
// Mac spezifische Eigenschaften

Klasse OperationSystemWindows extends OperationSystem:
//Windows spezifische Eigenschaften
[/highlight]


Und hier ist mein Problem:

In meinem Programm wollte ich ein "globales" OperationSystem-Objekt haben mit dem ich, je nach Betriebssystem, auf die Eigenschaften zugreifen kann.

Nur wie kann ich zur Laufzeit ein Objekt erzeugen mit dem ich auf die Eigenschaften des BS zugreifen kann ohne das ich immer, egal welches BS, ein Mac, Windowsobject etc. habe?

Sprich:
[highlight=Java]
OperationSystemMac osm;
OperationSystemWin owin;
OperationSystem os = new OperationSystem();

//Bsp Mac
if(os.getOperationSystem instanceof OperationSystemMac) {
osm = os.getOperationSystem();
}

Mit der oben beschriebenen Variante müsste ich ja nun im Programmcode immer abfragen:

if(osm != null) {
...
}
else if(owin != null) ....
[/highlight]

Wie kann ich vorgehen das ich in einem Objekt meine spezifiscehn Einstellungen für das Betriebssystem habe?
Sprich ein globales Objekt das mein Betriebssystem repräsentiert.
Ist der Weg über eine Schnittstelle, abstrakte Klasse evt. der richtige Weg?

Vielen Dank für eure Hilfe
Tobi

 

[hdi]

Hm.. Ich weiss jetzt nicht welche Infos du sammeln willst, und inwiefern die sich unterscheiden.

Ich schätze das beste ist ein Interface (oder abstrakte Klasse, kommt aufs gleiche raus)
Das nennst du "OSBehaviour" und es stellt bestimmte Methoden zur Verfügung, und zwar
alle, die irgendwo in irgendwelchen Systemen vorkommen könnten.

Dann machst du dir davon implementierungen:

WinBehaviour implements OSBehaviour usw.

Du implementierst nur die Methoden die du brauchst für dieses OS und lässt die anderen
leer, oder gibst da Fehlermeldungen zurück whatever.

Deiner Klasse OperatingSystem gibts du jetzt lediglich eine Member-Variable von
diesem Interface ("OSBehaviour myBehaviour"), zB im Konstruktor gleich wenn du
weisst welches OS konkret verwendet wird.
Sowas ist besser als Vererbung/Implementierung und nennt sich "Komposition".

Ja...und dann rufst du überall nur die Methoden dieser OperatingSystem-Instanz auf,
die jetzt global ist, und Aufrufe an ihre Member-Variable delegiert, die eine konkrete
Implementierung irgendeines OS-Behaviours ist.

Jetzt musst du nur wissen wie du die Methoden kapselst, d.h. wie du allgemeine
Methoden in dem OperatingSystem-Objekt zur Verfügung stellen kannst, die dann
eben sinnvoll an ihr Behaviour delegieren.

... je nachdem wie stark unterschiedlich das Verhalten sein soll für je ein OS, musst du
dir das zusammenbiegen.

Die Idee hier wär aber eben dieses Verhalten:
Eine Klasse hat (und erbt nicht) ein Interface, beim Instantiieren gibst du ihr eine
konkrete Implementierung des Interfaces.
Die Klasse deligiert (leitet weiter) an ihr Interface-Objekt, und ohne zu wissen welche
konkrete Implementierung das nun ist (WinBehaviour, MacBehaviour usw), passiert entsprechendes, oder eben nicht.

Naja, ob das jetz so gut rüberkam?!

edit:
Mal n Bsp damit du siehst in welche Richtung es geht:

[HIGHLIGHT="Java"]interface SoundBehaviour{
public void makeSound();
}

class Animal{
private SoundBehaviour mySnd;

public Animal(SoundBehaviour mySnd){
this.mySnd = mySnd;
}

public void makeSound(){
mySnd.makeSound(); // Delegation
}
}

class DogSound implements SoundBehaviour{
@Override
public void makeSound(){
System.out.println("Wuff!");
}
}
class CatSound implements SoundBehaviour{
@Override
public void makeSound(){
System.out.println("Miau!");
}
}

// main Methode:
Animal[] animals = new Animal[2];
animals[0] = new Animal(new DogSound());
animals[1] = new Animal(new CatSound());

// Hier globaler Einsatz: Du weisst es ist n Tier, aber welches weisst du nicht
for(int i = 0;i<animals.length;i++){
animals.makeSound(); // aber es wird konkret reagiert
}[/HIGHLIGHT]

 

[Illuvatar]

Sowas ist besser als Vererbung/Implementierung und nennt sich "Komposition".

Vielleicht sollte man auch erwähnen warum - weil das die Klassen weniger stark voneinander abhängig macht. Vererbung ist eine sehr starke Abhängigkeit.

Allerdings glaub ich, du erschlägst den armen tobbworld gerade ein bisschen - auch wenn du noch so recht hast. Aber angenommen man würde es so machen wollen, wie tobbworld es versucht - was ja auch nicht verkehrt ist, wenn auch eben nicht perfekt - dann würde das so aussehen.

Als Beispiel für so eine OS-spezifische Eigenschaft verwende ich mal den file-separator. Bitte beachten: das ist nur zu Demonstrationszwecken, den kriegt man nämlich besser aus System.getProperty("file.separator").

[HIGHLIGHT="Java"]
public abstract class OperatingSystem
{
public abstract String getFileSeparator();
}
public class WinOS extends OperatingSystem
{
public String getFileSeparator()
{
return "\\";
}
}
public class UnixOS extends OperatingSystem
{
public String getFileSeparator()
{
return "/";
}
}

// Verwendung:

OperationSystem os;
if (/*windows*/) {
os = new WinOS();
} else if (/*unix*/) {
os = new UnixOS();
} else if (/*mac*/) {
throw new IDontLikeThisOSException(); // :bae:
} else {
throw new UnsupportedOSException();
}

// ...

String fileSeparator = os.getFileSeparator();
[/HIGHLIGHT]

 

[didjitalist]

würds wahrscheinlich mit ner factory methode machen

public abstract class OperationSystem
{
  public static OperationSystem getCurrentOS()
  {
     if( /* win */ )
        return new WinOS();
     if( /* OSX */ )
        return new MacOS();
     // etc.
  }
}

wenns "global" sein soll, kannst du die entsprechenden OS objekte auch einfach statisch vorhalten und immer dasselbe objekt zurückliefern.

 

[tobbworld]

Hallo,

erst einmal vielen Dank für die zahlreichen und vor allem hilfreichen Beiträge. Wenn will ich es diesmal richtig machen und habe mich für die Lösung von "hdi" entschieden ;D
Hat wunderbar funktioniert. Hier meine implementierte Lösung für alle die irgendwann einmal das selbe Problem haben sollten:

Main- Klasse:

[highlight=Java]
public static void main(String[] args) {

OperationSystem os = null;

// Fallunterscheidung Betriebssystem
String osName = System.getProperty("os.name").toLowerCase();
if(osName.startsWith("windows")) os = new OperationSystem(new WinBehavior());
if(osName.startsWith("mac os x")) os = new OperationSystem(new MacBehavior());

// Abrufen der systemspezifischen Eigenschaften
System.out.println("OS => " + os.getName());
System.out.println("Java => " + os.getJavaVersion());
}
[/highlight]

OperatingSystem Klasse:

[highlight=Java]
public class OperatingSystem {

private OSBehavior myOS;


public OperatingSystem(OSBehavior myOS) {
this.myOS = myOS;
}


public String getName() {
return myOS.getName();
}

public String getFileSeperator() {
return myOS.getFileSeperator();
}

// Methoden die für jedes OS gleich sind
public String getJavaVersion() {
return System.getProperty("java.version");
}


}
[/highlight]

OSBehavior Klasse (Schnittstelle):

[highlight=Java]
public interface OSBehavior {

public String getFileSeperator();

public String getName();

}
[/highlight]

WinBehavior Klasse:

[highlight=Java]
public class WinBehavior implements OSBehavior{

public WinBehavior() {

}

public String getFileSeperator() {
return "\\";
}

public String getName() {
return "Windows";
}
}
[/highlight]

MacBehavior Klasse:

[highlight=Java]
public class MacBehavior implements OSBehavior{

public MacBehavior() {

}

public String getName() {
return "MacOS";
}

public String getFileSeperator() {
throw new UnsupportedOperationException("Not supported yet.");
}

}
[/highlight]

Anmerkung: Den Fileseperator ziehe ich sonst auch aus den Systemproperties, Methode war jetzt nur für Demonstrationszwecke

 

[maki]

Wie wäre es mit einer Factory Methode welche gleich das passende Objekt zurückliefert?

 

[tobbworld]

Hey maki,

wie meinst du das genau? Wenn ich die Variante von didjitalist benutze muss ich doch in meinem Hauptprogramm immer noch unterscheiden mit welchen Objekt ich jetzt arbeite, oder nicht?

 

[maki]

Wenn ich die Variante von didjitalist benutze muss ich doch in meinem Hauptprogramm immer noch unterscheiden mit welchen Objekt ich jetzt arbeite, oder nicht?

Nö, wenn du digitalists Vorschlag folgst, musst du genau das nicht mehr machen und deine main Klasse würde kleiner werden

 

[hdi]

Ich weiss auch nich ob ich genau die Definition von Factory kenne, ich glaube er meint
aber einfach nur dass du den Code in der main, der das OS bestimmt, auslagerst
in eine Hilfsklasse:

OperationSystem os = OSFactory.getOS(); // in getOS() dann die Berechnungen vornehmen

vllt meint er das aber auch nicht.

 

[maki]

Ja HDI,genau das meinte digitalist und ich auch.

Es gibt mehrere Wege dafür, von statischen Factory Methoden bis hin zu Factory Klassen, wobei ersteres hier besser wäre.

 

[hdi]

Ja, aber alleine die Auslagerung des Codes ist nicht das, was man ein Factory Pattern nennt, denk ich.
Ist also hier vllt grad noch so eine Pseudo-Factory...

 

[maki]

Ja, aber alleine die Auslagerung des Codes ist nicht das, was man ein Factory Pattern nennt, denk ich.
Ist also hier vllt grad noch so eine Pseudo-Factory...

Keine Pseudo Factory!
Die Kapselung des Codes um ein Objekt zu erstellen ist genau das was eine Factory ausmacht

Aufrufer müssen nun nicht mehr wissen was alles nötig ist um ein Objekt zu stellen.
Wenn man statt einer konkreten Implementierung ein Interface zurückgibt, weiss der Aufrufer nichtmal um welche Implementierung es sich handelt.
Ausserdem können Factories anders als Konstruktoren sprechende Namen haben.
Man kann Factories aber auch einsetzen wenn immer nur diesselbe Implementierung erzeugt wird, aber die Erzeugung des Objektes kompliziert/aufwändig ist oder um die Internas zu verstecken.

 

[tobbworld]

Keine Ahnung ob ich euch jetzt richtig verstanden habe:

Habe am Beispiel mit Interfaces hätte ich es jetzt so gelöst:

In der Main- Klasse:

[highlight=Java]
os = OperatingSystem.getOS();[/highlight]

Operating System:
[highlight=Java]
public class OperatingSystem {

private OSBehavior myOS;


public OperatingSystem(OSBehavior myOS) {
this.myOS = myOS;
}


public String getName() {
return myOS.getName();
}

public String getFileSeperator() {
return myOS.getFileSeperator();
}


public String getJavaVersion() {
return System.getProperty("java.version");
}


public static OperatingSystem getOS() {
// zum Test nur mal Windows....
return new OperatingSystem(new WinBehavior());
}

}
[/highlight]

Wenn ich den Vererbungs Ansatz verfolge würde es bei mir so aussehen:

[highlight=Java]
public abstract class OperatingSystem
{
public abstract String getFileSeparator();


public static OperatingSystem getCurrentOS()
{
if( /* win */ )
return new WinOS();
if( /* OSX */ )
return new MacOS();
// etc.
}
}
public class WinOS extends OperatingSystem
{
public String getFileSeparator()
{
return "\\";
}
}
public class UnixOS extends OperatingSystem
{
public String getFileSeparator()
{
return "/";
}
}

// Verwendung:

OperatingSystem os = OperatingSystem.getCurrentOS();

String fileSeparator = os.getFileSeparator();
[/highlight]

Meine Frage nun noch dazu, welcher Ansatz ist besser und performanter? Der über Interfaces oder über Vererbung?

Viele Grüße
Tobi