UML korrekt umgesetzt?

[shizzzle*]

Komme mit einer HA nicht weiter.

Die Aufgabenstellung gibts hier:
Aufgabe (PDF)


Und das habe ich soweit Prgrammiert:


Klasse Maschine:

package ueb001;

public class Maschine {

private int dauer;
private double tarifTag;


public Maschine(double tarifTagIn, int dauerIn){
	this.tarifTag = tarifTagIn;
	this.dauer = dauerIn;
	}

public double getMietpreis(){
	return 0;
	}
}

Klasse Kfz:

package ueb001;

public class Kfz extends ueb001.Maschine {


//Attribute
private int km;
private double tarifKm;

//Konstruktor
public Kfz(double tarifTagIn, int dauerIn, double tarifKmIn, int kmIn){
	super(tarifTagIn, dauerIn);
	this.tarifKm = tarifKmIn;
	this.km = kmIn;
}

//get Methode
public double getMieptreis(){
	return 0;
		 }
}

Erstmal, ist das reine UML richtig von mir umgesetzt?
Eine weitere Frage:
Wo mache ich die Berechnung? Muss ich dafür eine dritte Klasse mit set-Methoden erstellen? Aber davon steht ja nichts drin. Steh grade auf dem Schlauch

 

[ARadauer]

ich würd die berechnung in der getMietpreis Methode machen und den berechneten wert einfach zurück geben

 

[shizzzle*]

public class Kfz extends ueb001.Maschine {



private int km;
private double tarifKm;

public Kfz(double tarifTagIn, int dauerIn, double tarifKmIn, int kmIn){
	super(tarifTagIn, dauerIn);
	this.tarifKm = tarifKmIn;
	this.km = kmIn;
}

public double getMieptreis(){
	return (tarifTag * dauer) + (tarifKm * km);
		 }
}

Quasi so? Bekomme ne Fehlermeldung

"The Field Maschine.tarifTag is not visible"
"The Field Maschine.dauer is not visible"

 

[maki]

Das UML Diagramm ist falsch

imho sollte tarifTag und dauer protected anstatt private sein.

Entweder das oder du nutzt die getter und setter der Oberklasse (super.get...), aber dann wäre Vererbung wohl falsch und Komposition zu bevorzugen.

 

[Guest]

Das UML Diagramm ist falsch

imho sollte tarifTag und dauer protected anstatt private sein.

Entweder das oder du nutzt die getter und setter der Oberklasse (super.get...), aber dann wäre Vererbung wohl falsch und Komposition zu bevorzugen.

Wie UML ist falsch? Ich habe leider keine Ahnung was du meinst ;-)

set methoden stehen doch nicht in der aufgabe oder? Und variable als protected gesetzt hatten wir im unterricht noch nicht also kanns daran nicht liegen.

 

[maki]

Wie UML ist falsch?

Aus wikipedia:

Falschheit bezeichnet im Allgemeinen die Eigenschaft eines Gedankens oder einer Aussage, nicht mit der Realität übereinzustimmen.

Ich habe leider keine Ahnung was du meinst icon_wink.gif

Offensichtlich

Und variable als protected gesetzt hatten wir im unterricht noch nicht also kanns daran nicht liegen.

Ach, und dort wird festgelegt was geht und was nicht?
Ich möchte jetzt nicht auf die PISA Studie eingehen, aber das UML Diagramm ist nunmal nicht richtig so.

 

[VuuRWerK]

In der Tat ist hier die Vererbung nicht richtig eingesetzt wurden. Aber vllt will Dein Lehrer soetwas sehen:

public class Maschine
{
    private double tarifTag;
    private int dauer;

    public Maschine( double tarifTagIn, int dauerIn ) {
        this.tarifTag = tarifTagIn;
        this.dauer = dauerIn;
    }

    public double getMietpreis() {
        return( this.tarifTag * this.dauer );
    }
}

public class Kfz extends Maschine
{
    private int km;
    private double tarifKm;

    public Kfz( double tarifTagIn, int dauerIn, double tarifKmIn, int kmIn ) {
        super( tarifTagIn, dauerIn );
        this.tarifKm = tarifKmIn;
        this.km = kmIn;
    }

    public double getMietpreis() {
        return( super.getMietpreis() + this.tarifKm * this.km );
    }
}

Wie gesagt keine wirkliche Vererbung dabei aber vllt meinte es Dein Lehrer so oder er hat schlichtweg das UML falsch gemacht

Gut Schuß
VuuRWerK

 

[Guest]

Wie UML ist falsch?

Aus wikipedia:

Falschheit bezeichnet im Allgemeinen die Eigenschaft eines Gedankens oder einer Aussage, nicht mit der Realität übereinzustimmen.

Ich habe leider keine Ahnung was du meinst icon_wink.gif

Offensichtlich

Und variable als protected gesetzt hatten wir im unterricht noch nicht also kanns daran nicht liegen.

Ach, und dort wird festgelegt was geht und was nicht?
Ich möchte jetzt nicht auf die PISA Studie eingehen, aber das UML Diagramm ist nunmal nicht richtig so.

Schlaumeier!

Ne das vielleicht nicht aber mein Lehrer wird sich bei der Aufgabe ja schon etwas gedacht haben.

 

[maki]

Menschen machen Fehler.

Wir haben ein paar Lehrer hier, vielleicht vertraust du deren Autorität eher als mir.

In dieser Aufgabe ist definitiv der Wurm drinn, so oder so.

 

[Gast]

Und was soll bitteschön falsch an dem UML sein?

tarifTag und dauer sind doch so lange sie private sind ganz gut gekapselt.

Wenn man zuerst Maschine implementiert, ohne von KFZ etwas zu erahnen, wird man die Variablen privat setzen. Hat man dies gemacht ist Maschine fertig, korrekt, getestet und man sollte auch nichts mehr daran ändern.

Teile der Berechnung von Maschine#getMietpreis(), also tarifTag * dauer wären im falle von protected doch redundant implementiert. Obwohl es sich hier nur um eine einfache Multiplikation handelt.

Und wenn man meint das das statt private protected sein muß, dann muß!!! man auch so konsequent sein und auf private vollkommen verzichten und darf nur noch protected verwenden.

 

[maki]

Und was soll bitteschön falsch an dem UML sein?

Ich finde das sehr unüblich (in Java), schliesslich wird in der Vererbungshierachie nur getMietpreis() vererbt.
Dafür sind Interfaces besser geeignet.

tarifTag und dauer sind doch so lange sie private sind ganz gut gekapselt.

Eben, so "gut" dass nicht mal abgeleitete Klasen darauf zugreifen können, sie werden ja nicht vererbt.
Vererbung und Kapselung beissen sich regelmässig.
In so einem Fall nimmt man doch lieber Komposition anstatt Vererbung.

Wenn man zuerst Maschine implementiert, ohne von KFZ etwas zu erahnen, wird man die Variablen privat setzen. Hat man dies gemacht ist Maschine fertig, korrekt, getestet und man sollte auch nichts mehr daran ändern.

Man könnte jetzt einfach ein Maschine Objekt instanziieren, ist das sinnvoll?
Das man daran nichts mehr ändern kann ist übrigens kein Vorteil.
Unittests bleiben, prüfen ob die Klasse nach einem refactoring immer noch funktioniert.

Teile der Berechnung von Maschine#getMietpreis(), also tarifTag * dauer wären im falle von protected doch redundant implementiert. Obwohl es sich hier nur um eine einfache Multiplikation handelt.

Nicht redundant, sondern die Basisklasse bietet eine Standardimplementierung welche von abgeleiteten Klassen entweder benutzt werden kann oder ganz anders implementiert.

Und wenn man meint das das statt private protected sein muß, dann muß!!! man auch so konsequent sein und auf private vollkommen verzichten und darf nur noch protected verwenden.

Ja, und so kenn ich das aus Java heraus

Wie wäre es damit:
Ein Interface Maschine

public interface Maschine {
    public double getMietPreis();
}

Ein abstrakte Klasse AbstractMaschine, weche das Interface Implementiert

public abstract AbstractMaschine 
implements Maschine {
    
    protected double tarifTag;

    protected int dauer;

    public double getMietPreis() {
        return (tarifTag * dauer); 
    }
}

So, jetzt kommen die konkreten Implementierungen, wie KFZ:

public class KFZ
extends AbstractMaschine {
 
    protected double tarifKm;
    protected int km;

    public double getMietPreis() {
        return super.getMietPreis() + (tarifKm * km); 
    }

}

So ist man wirklich flexibel
Auf diese Art kann man jederzeit Funktionalität zur Basisklasse hinzufügen, ohne notwendigerweise alle Unterklassen mitabzuändern. Das ist wichtig für Klassenhierarchien die von anderen mitverwendet werden.
Es reicht zB eine neue Methode im Interface zu definieren und diese Methode dann in der abstrakten Basisklasse implentieren.
Als Beispiel seien hier die Java Collections genannt

 

[Gast]

Man könnte jetzt einfach ein Maschine Objekt instanziieren, ist das sinnvoll?

JA.

In der Aufgabenstellung steht, es sollen auch Maschinen ausgeleiht werden können. Kein Grund AbstractMaschine abstract sein zu lassen. Noch dazu, das AbstractMaschine keine abstracte Methode beinhaltet.

Das nur eine Methode vererbt wird, soll eher der Übersichtlichkeit der Übungsaufgabe dienen.

Wenn es keinen Sinn macht private zu verwenden macht es ebensowenig Sinn protected, oder default zu verwenden. Dann bitteschön alles public.

Unittests bleiben, prüfen ob die Klasse nach einem refactoring immer noch funktioniert.

Unittests bedeuten immer Aufwand. Und wenn es nur die 2 sec. sind die man benötigt um ihn unnötigerweise laufen zu lassen.

 

[Guest]

In der Tat ist hier die Vererbung nicht richtig eingesetzt wurden. Aber vllt will Dein Lehrer soetwas sehen:

public class Maschine
{
    private double tarifTag;
    private int dauer;

    public Maschine( double tarifTagIn, int dauerIn ) {
        this.tarifTag = tarifTagIn;
        this.dauer = dauerIn;
    }

    public double getMietpreis() {
        return( this.tarifTag * this.dauer );
    }
}

public class Kfz extends Maschine
{
    private int km;
    private double tarifKm;

    public Kfz( double tarifTagIn, int dauerIn, double tarifKmIn, int kmIn ) {
        super( tarifTagIn, dauerIn );
        this.tarifKm = tarifKmIn;
        this.km = kmIn;
    }

    public double getMietpreis() {
        return( super.getMietpreis() + this.tarifKm * this.km );
    }
}

Wie gesagt keine wirkliche Vererbung dabei aber vllt meinte es Dein Lehrer so oder er hat schlichtweg das UML falsch gemacht

Gut Schuß
VuuRWerK

Und wie geb ich das jetzt in der Konsole aus?

System.out.println(getMiepreis()); ?

 

[shizzzle*]

package ueb002;

public class Maschine {

    private double tarifTag;
    private int dauer;
    
    public Maschine(double tarifTagIn, int dauerIn){
    	this.tarifTag = tarifTagIn;
    	this.dauer = dauerIn;
    }
    
    public double getMietpreis(){    	
    	return this.tarifTag * this.dauer;
    }
}

package ueb002;

public class Kfz extends Maschine {

	private double tarifKm;
	private int km;
    
    public Kfz(double tarifTagIn, int dauerIn, double tarifKmIn, int kmIn){
    	super(tarifTagIn, dauerIn);
    	this.tarifKm = tarifKmIn;
    	this.km = kmIn;
    }
    
    public double getMietpreis(){    	
    	return super.getMietpreis() + this.tarifKm * this.km;
    }
    public static void main(String []args){
    	System.out.println("Der Miepreis beträgt: " +getMietpreis());
    }
 }

Soweit funktioniert jetzt alles. Bis auf den Test ob die Berechnung wirklich funktioniert. Bei der Ausgabe kommt vom Compiler folgender Fehler:

"Cannot make a static reference to the non-static method getMietpreis() from the type Kfz"

Habe schon alles möglich ausprobiert. Bekomme es aber nicht hin.[/code]

 

[Ariol]

public static void main(String []args){
       KFZ kfz = new KFZ(100.0,3,1.50,350);
       System.out.println("Der Miepreis beträgt: " +kfz.getMietpreis());
    }