[Progra] Übung 9 Aufgabe 1

[Spobo]

Kann es sein, dass in der Aufgabenstellung total vergessen worden ist, zu erwähnen, in welcher Reihenfolge die Attribute in den (übrigens auch nicht erwähnten) Kontruktoren stehen sollen? Ich habs mir jetzt zusammengereimt aus der MobilTest.java, aber wenn das Absicht war, seh ich da keinen Sinn hinter..

[Coolcat]

Ok, wurde scheinbar wirklich vergessen...
Klasse Rechnung

Code: Alles auswählen

    /**
     * Erzeugt ein neues Objekt vom Typ <code>Rechnung</code>, in dem
     * die Parameter des Konstruktors gekapselt werden.
     *
     * @param vertrag der Vertrag, der der Kostenberechnung zugrunde liegt
     * @param monat der Abrechnungsmonat
     * @param gesamtMinuten die Minuten, die insgesamt im Abrechnungsmonat
     *  telefoniert wurde
     * @param anzahlAnrufe die Anzahl der getaetigten Anrufe im
     *  Abrechnungsmonat
     * @param anzahlSMS die Anzahl der im Abrechnungsmonat versandten
     *  SMS-Kurznachrichten
     */
    public Rechnung(MobilVertrag vertrag, String monat,
            int gesamtMinuten, int anzahlAnrufe, int anzahlSMS) { /* ... */ }

Klassen LongCall, Kidz, FlexiFlat und SimplyFlat

Code: Alles auswählen

    /**
     * Erzeugt ein neues Objekt vom Typ <code>Longcall</code>, in dem
     * die Parameter des Konstruktors gekapselt werden.
     *
     * @param inhaber der Inhaber des Vertrages
     * @param telefonnummer die mit dem Vertrag verknuepfte Telefonnummer
     */
    public LongCall(Person inhaber, String telefonnummer) { /* ... */ }

[Spobo]

mir ist grad noch aufgefallen, dass die musterausgabe eigentlich nicht stimmt, denn wenn man person.toString nutzt und das ist ja durchaus sinnvoll, wird noch das gebutsdatum an die ausgabe das namens gehangen;)

[aRo]

ich habe auch einmal eine Frage:
Wozu braucht man eigentlich das Interface "MobilVertrag"?
Ich meine, hätte man dieses Interface nicht weglassen können und die entsprechenden Forderungen direkt in die AbstractMobilVertrag packen können?

Der Vorteil von interfaces ist doch, dass sie sozusagen Mehrfachvererbung ermöglichen. "MobilVertrag" wird jedoch nicht mehrfach vererbt.

Danke euch und schöne Feiertage!

[Coolcat]

Nun ja es könnte ja jetzt irgendeinen anderen Anbieter geben der vielleicht eine Kombination von Telefon, Internet und Handy anbietet.

Dann würde man die Interfaces TelefonVertrag, InternetVertrag und MobilVertrag in einer Klasse implementieren.

[aRo]

hm, ja gut.
Brauche das auch irgendwie für die 2.Aufgabe:
Wann verwendet man üblicherweise Inferfaces?
- Wenn man Mehrfachvererbung ermöglichen will

und sonst? Was gibts sonst für Gründe?
Bin mir bei der 2a) nicht immer ganz sicher, was nun abstract und was ein Interface werden soll.

[Coolcat]

Bin mir bei der 2a) nicht immer ganz sicher, was nun abstract und was ein Interface werden soll.

Nun es ist ja grob eine Hierarchie vorgegeben, wenn man die Aufgabe ließt. Das können alles normale Klassen sein. Dann gibt es aber noch einige Eigenschaften die sich quer durch diese Hierarchie ziehen, dafür nimmt man dann Interfaces.
(ggf. einfach mal ein paar alte Aufgaben angucken )

[aRo]

und wieso nimmt man dafür interfaces und keine abstrakten Klassen?

So wie ich das bisher verstehe, lässt sich das, was man mit einem Interface machen kann, auch mit einer abstrakten Klasse machen, sofern es keine Klasse gibt die Mehrfachvererbung braucht.

[Coolcat]

Vielleicht weil man die Mehrfachvererbung braucht?

[aRo]

naja, gut, ich sehe, dass sie alles um die Mehrfachvererbung dreht. Ich denke ich weiß, wie die Aufgabe gemeint ist. Danke dir und schönen Abend noch!

[mirko]

guck dir beispielsweise mal die musterlösung des 9. übungsblattes von 2005 an (s. http://verify.rwth-aachen.de/programmie ... /blaetter/ )

dort geht es um Sehhilfen. Die "Kontaktlinse" ist einerseits eine "ZweiOptikenSehhilfe" (wie auch Brille und insbes. Sonnenbrille) und andererseits "Begehrt" (hier geht es darum, dass begehrte sehhilfen eine wertermittlung über eine methode getWert() ermöglichen). Wären "ZweiOptikenSehhilfe" und "Begehrt" beides abstrakte klassen, könnte die "Kontaktlinse" nicht gleichzeitig von beiden erben. dieses problem wird gelöst, indem man "Begehrt" als interface deklariert.

was coolcat mit der hierarchie meint, ist: brille und kontaktlinse sind "ZweiOptikenSehhilfen". das ist vollkommen klar und daraus kann man ganz gut eine hierarchie aufbauen. diese "Begehrt"-Klasse (bzw. interface) passt in die ganze hierarchie nicht so wirklich rein. deswegen definiert man "Begehrt" als interface.

edit: mist, zu langsam

[zorgblaubaer]

in meiner lösung wird der jahrgang des inhabers mit ausgegeben. gibt es dafür punktabzug oder ist das so in odnung?

[Coolcat]

@zorgblaubaer:

mir ist grad noch aufgefallen, dass die musterausgabe eigentlich nicht stimmt, denn wenn man person.toString nutzt und das ist ja durchaus sinnvoll, wird noch das gebutsdatum an die ausgabe das namens gehangen;)

Ist schon in Ordnung.

[jogla]

Hallo,

mir wird da auch etwas nicht ganz klar.
Bei der 1.b) IV, wie kann ich denn mit einer Implementierung von getAnzahlFreieSMS() und getKostenProWeitererSMS() dieses Abrechnungsform abbilden? Wenn ich ihn getAnzahlFreieSMS() oder getKostenProWeitererSMS() die Anzahl der SMS, die verschickt worden sind, wissen wuerde, dann wuerde ich das irgendwie hinbekommen, aber so sehe ich da keine Change.

Ich kann das natuerlich in die AbstractMobilVertrag rein hacken, aber dass das so vorgesehen war, kann ich mir nicht vorstellen. (Mit instanceof FlexiFlat)

Kann mir da mal jemand einen Anstoss geben?

Gruss Jonathan

[Coolcat]

Die ML gibt in getAnzahlFreieSMS() einfach 0 und in getKostenProWeitererSMS() einfach 0.1 zurück.