Vererbung und Komposition??

Diskutiere Vererbung und Komposition?? im Allgemeine Java-Themen Bereich.
M

MiMa

Hi,
aktuell möchte Daten aus Dateien ermitteln und in entsprechende Objekte speichern.
Dabei habe ich schon einige Gedanken gemacht und möchte mal nach anderen Meinungen fragen.

1. Eine Datei ist ein Element welches sich auf einen Datenträger befindet und in Java über File angesprochen werden kann
Diese Datei hat Eigenschaften wie, Dateiname, Erstellungsdatum, Änderungsdatum, ....
2. Der Dateityp kann durch die Dateiendung oder den MIME Type aus einer Datei ermittelt werden und enthält wieder andere
Informationen, die in der Datei selbst nicht enthalten sind und dort auch nicht gespeichert werden können.
3. Eine weitere Einteilung nenne ich mal Dokumentart und diese definiert um welche Art von Inhalt es dich dabei handelt.

Beispiel von Dokumentarten: Fotos, Rechnungen, ...
Fotos ist von der Dokumentart "Bilder" enthält den Dateiyp "bmp, jpg, tif,..." und ist eine Datei.
Rechnung ist von der der Dokumentart "Korrespondenz" enthält den Dateityp "pdf, office-paket, jpg" und ist eine Datei

Dabei ist die Klasse "Datei" die oberste Klasse.
Da es sich immer und Dateien handelt denke ich das der Dateityp immer von Datei erben kann.

Bei der Dokumentart handelt sich nicht immer um den gleichen Dateityp.
Ein Foto kann ein jpg, bm, ein Tiff oder etwas anderes sein und daher denke ich das eine Vererbung nicht das richtige wäre??
Auch eine Rechnung kann vom Dateityp ein Gesantes JPG, eine pdf oder ein Word Dokument sein.
Dabei müsste man den Wert von extends im Java code durch eine Variable ergänzen und dann die jeweilige Vererbung zur
Laufzeit entscheiden?
 
L

LimDul

Dabei müsste man den Wert von extends im Java code durch eine Variable ergänzen und dann die jeweilige Vererbung zur
Laufzeit entscheiden?
Das geht nun mal gar nicht. Vererbung muss zur Compile Zeit feststehen.

Warum soll Dateityp von Datei erben? ist Dateityp eine Datei? Also hat Dateityp eine Eigneschaft wie Dateiname, EresstellungsDatum etc.? DateiTyp ist für mich eher ein Attribut von Datei. Grundsätzlich gilt, Vererbung nur dann, wenn die Subklasse eine is A Beziehung hat.

Das heißt, wenn du B extends A hast, dann musst du an jeder Stelle (fachlich bzw. im Code), wo du A sagst auch B sagen können. Wenn A die Eigenschaft X hat, dann muss auch bei eine Eigenschaft X haben. Wenn ich sage "Ich kann an der Stelle X benutzen, z.B. als Ausgabe auf die Konsole" dann muss an der Stelle auch B nutzen können. Und das hört sich bei mir bei Dateityp schon schräg an.

In vielen Fällen ist wirklich die Komposition der Vererbung vorzuziehen.
 
MoxxiManagarm

MoxxiManagarm

extends bedeudet übersetzt "ist ein"
Ein Attribut bedeudet "hat ein"

Ich kann mich recht gut an ein Beispiel hier aus dem Forum erinnern, wo selbst ein Prof das über den Haufen geworfen hatte. Da sollte einer seinen Quader (vielleicht wars auch ein anderer Körper, weiß nicht mehr) von Rechteck erben lassen und dann das Attribut für die Höhe ergänzen. Rein Syntaktisch ist das möglich. Das würde aber bedeuten: "Der Quader (Körper) ist ein Rechteck (Fläche)", was fachlich gesehen totaler Humbuk ist. Richtig wäre stattdessen: Der Quader hat eine rechteckige Grundfläche und eine Höhe.

Und genau diese Formulierung musst du dir immer vor Augen halten.
 
M

MiMa

Naja, in gewisser weise hast du recht, wenn du sagst das der Dateityp ein Dateiattribut ist, aber durch dieses Attribut kann ich halt unterscheiden, welche weitere Daten ich im weiteren Objektverlauf speichern kann.
Eine Worddatei enthält andere Daten als ein pdf oder jpg.
Wenn ich den Dateityp von Datei erben lasse, kann ich Daten bei pdf Attribute wie Titel, Verfasser, Thema, Stichwörter usw. definieren als bei einem jpg, wo ich Metadaten aus dem exif Bereich defineren kann.
Bei einer Vererbung kann ich dann dem Dateityp entsprechende Informationen speichern.
In der Klasse Dokumenrart Rechnung kann ich dann Werte definieren wie Empfänger, Absender, Betrag, Bezahlt, ...
Rechnung "enthält" pdf Werte und "ist" eine Datei
Wäre das dann eine Komposition?
Datei <-- pdf und Dokument weis ich jetzt nicht wie?
 
MoxxiManagarm

MoxxiManagarm

Bei Rechnung stimme ich dir auf gar keinen Fall zu, dass diese eine Datei IST, sofern sie die genannten Werte enthält. Ich würde eher sagen eine Rechnung HAT einen PDF-Rechnungsdokument.
 
T

temi

Ich glaube das ist alles etwas zu akademisch. Letztlich geht es doch darum, was er modellieren möchte und für die erforderliche Aufgabe, braucht er die passenden Typen.

Natürlich kann man Tiere in eine Klassenhierarchie in der Art von Tier - Vogel - Blaumeise modellieren, aber wenn ich eine, sagen wir mal, Tierbeobachtungsverwaltung programmiere, dann würde ich ja niemals die Klassen Tier, Vogel, Blaumeise implementieren.

So wie ich dich verstanden habe, möchtest du diverse Dateien einlesen und klassifizieren. So wie in einem Dateimanager. Oder?
 
M

MiMa

@temi ja du hast es erfasst. Ich suche Hilfe zur Modellierung um entsprechende Objekte zu erhalten um dort Daten unter zu bringen.
Ich habe mehrere Millionen von Dateien zu sortieren, auf doppelte zu prüfen, zu löschen und zu sortieren.
Mein Programm soll mir helfen das möglichst effizient und so selbstständig wie möglich zu machen.
Alles was ich verwalten möchte sind Dateien also nichts was man physisch anfassen kann.
Und zum Beispiel von Rechnung muss es nicht unbedingt ein PDF-Rechnungsdokument sein, sondern kann auch eine mit Word geschriebene Datei sein. Allerdings kann eine Rechnung auch ein gescanntes jpg oder tif sein, welches dann aber erkannt wird und automatisch mir OCR in ein pdf gewandelt wird und dann erneut klassifiziert wird.
 
Zuletzt bearbeitet:
M

MiMa

Damit es einfacher zusammengesetzt werden kann.
Außerdem enthält die Klasse "Datei" nicht nur die Instanzvariablen und den Konstruktor, sondern auch alles was ich mit Dateien anstellen will wie spezielle Methoden zur Duplikatprüfung, verschieben in verschiedene Verzeichnisstrukturen Prüfsummenberechnung, usw.
Die Klassen für Dateityp enthält neben den Instanzvariablen für genau diese die entsprechende Methoden zur Verwaltung Ermittlung und Eintragungen. Die Klasse Buch zum Beispiel enthält zu den Variablen auch die Methoden zum ermitteln der ISBN aus einem Dateiinhalt, zum Parsen mit der Deutschen Nationalbibliothek und speichert alle Informationen die zurückgegeben werden und trägt alle Werte in die entsprechenden Positionen in einer PDF. Auch die Klassen Schriftverkehr und Rechnungen erhalten alle Informationen aus den Dateiinhalten und mit verschiedenen Algorithmen werden die entsprechenden Metainformationen gesammelt und in die Datei implementiert.
Da sind Klassen doch ganz sinnvoll.
 
F

fhoffmann

Dass ein "Dateityp" von "Datei" erben soll, klingt wirklich komisch. Aber natürlich kann man sagen, dass "PdfDatei" oder "TifDatei" von "Datei" erben.

Dennoch wäre ich eher ein Freund der Komposition (Eine Datei hat einen Dateityp). Insbesondere, wenn du ein Tif-Datei in eine PDF-Datei änderst, könntest du das mit Vererbung nicht realisieren (du kannst keine TifDatei in eine PdfDatei "casten"), wohl aber mit Komposition (du kannst der Datei einen neuen Dateityp geben).
 
M

MiMa

Wenn ich eine Datei untersuche, dann schaue ich mir erst den Inhalt an und Untersuche dann schrittweise.
Ist der Inhalt Bild oder Text.
Bei Text schaue ich nach bestimmten Eckdaten und finde z.B. eine Rechnung.
Dann muss das Objekt zusammengebaut werden.
Dokumentart Rechnung (Klasse Rechnung)
Ermittle den Dateityp (Word, PDF, usw.) und nehme dann das Ergebnis (Klasse PDF)
und da es sich immer um eine Datei Handelt (Klasse Datei)
Also aus diesen drei Klassen muss dann das Objekt gebaut werden
Datei + Pdf + Rechnung

Wenn eine Rechnung aus eine Worddatei gefunden wird sieht das dann anders aus
Datei + doc + Rechnung

Die Klassen der Dateitypen wie pdf enthält nur die pdf-spezifischen Daten die der Datei hinzugefügt werden.
Datei + pdf = PdfDatei (Datei Informationen mit den zusätzlichen PDF Informationen)
Datei + doc = Worddatei (Datei Informationen mit den zusätzlichen Word Informationen)

Wie die Konstellation genau ist hängt immer vom Inhalt der Datei ab.
Bei dieser flexiblen Modellierung tue ich mich ein bisschen schwer.

Wenn ich das mit der Komposition richtig verstanden habe, dann muss die Klasse "Rechnung" den zugehörigen Dateityp ermitteln und dann das Objekt bauen?
 
Zuletzt bearbeitet:
T

temi

Nehmen wir mal Datei - Rechnung - doc und Datei - Rechnung - pdf. Worin unterscheiden sich bei den beiden die Methoden? Was kann doc anders als pdf?

Für mich ist das bisher nur eine Art von Tagging.
 
F

fhoffmann

Was spricht gegen folgende Art der Komposition?
(Ich habe hier bereits ein Beispiel der Delegation einer Methode (tuWas()) mit angedeutet.)
Java:
class Dateityp {
    void tuWas() {
        // ...
    }
}
class DateitypPdf extends Dateityp {
    void tuWas() {
        // ...
    }
}
class DateitypTif extends Dateityp {
    void tuWas() {
        // ...
    }
}

class Dokumentart {
    // ...
}
class DokumentartRechnung extends Dokumentart {
    // ...
}

class Datei {
    Dateityp dateityp;
    Dokumentart dokumentart;

    void tuWas() {
        dateityp.tuWas();
    }
}
 
M

MiMa

@temi
Der Unterschied zwischen den Dateien Rechnung - doc und Rechnung - PDF sind die Speicherung der Daten.
Beide enthalten die gleichen Daten von Datei und Rechnung.
Bei der pdf werden die Rechnungsinformationen in Titel, Verfasser, Thema und Stichwörter verteilt und eingebettet.
Bei der doc werden die Rechnungsinformationen bei den Erweiterten Eigenschaften wie Titel, Thema, Autor, Firma, Kategorie, Stichwörter, Kommentare verteilt und eingebettet.

Je nach Dateityp werden die Daten unterschiedlich in die Datei eingebettet und daher habe ich mir überlegt diese Schnittstelle in eine Klasse mit dem jeweiligen Dateityp darzustellen.
 
M

MiMa

@fhoffman
In der Klasse Datei sind alle Daten, Methoden und Konstruktoren über die Datei.
In der Klasse Dateityp sind alle Daten , Methoden und Konstruktoren die Dateityp Spezifisch sind.
In der Klasse Dokumentart werden Daten ermittelt und den Dokumentarten zugewiesen.

Ich bin mir nicht klar was die Klasse DateitypPDF sein soll oder wie die Verbindung sind?
Bei mir im Projekt habe ich auch nicht solche Klassen?
Ich habe ein Package was Dateitypen heißt und dort sind die Klassen TypPdf, TypDoc, TypJPG, ... enthalten
Weitere Package sind Dokumentarten mit den Klassen Rechnung, Schriftverkehr, Buch, Fotos, ...
 
Zuletzt bearbeitet:
M

MiMa

@fhoffman
Ich habe auch das Gefühlt das du in deinem Beispiel zu viele Klassen hast.
Im Grunde muss ich 3 Klassen zusammensetzen um die entsprechenden Informationen zusammen zu setzen
TypPDF extends Datei mit der entsprechenden Rokumentart "Rechnung"
Datei <-- TypPDF <>--- Rechnung
Ich würde das mal als dynamische Vererbung beschreiben weil der PDFTyp ohne Datei nicht existieren kann.
Die Rechnung zwar ohne TypPDF existieren kann aber dann keine PDF Daten in die Datei integrieren kann. Sie kann aber auf keinen Fall ohne Datei existieren. Ich komme zur erkentnis
Datei <-- TypPDF (<-- dynamisch) Rechnung, irgendwie ??
 
Zuletzt bearbeitet:
F

fhoffmann

Da es sich immer und Dateien handelt denke ich das der Dateityp immer von Datei erben kann.
Ich habe ein Package was Dateitypen heißt und dort sind die Klassen TypDoc, TypJPG, ... enthalten
Verstehe ich es richtig, dass beispielsweise TypDoc von Datei erbt?

Ich habe auch das Gefühlt das du in deinem Beispiel zu viele Klassen hast.
Ich habe in meinem Modell auch nur drei "Typen", nämlich Datei, Dateityp und Dokumentart. Alle anderen Klassen erben davon.
 
T

temi

Bei der pdf werden die Rechnungsinformationen in Titel, Verfasser, Thema und Stichwörter verteilt und eingebettet.
Bei der doc werden die Rechnungsinformationen bei den Erweiterten Eigenschaften wie Titel, Thema, Autor, Firma, Kategorie, Stichwörter, Kommentare verteilt und eingebettet.
Du sprichst hier aber davon, wo oder wie die Daten in der eigentlichen Datei gespeichert sind, oder?

Das hat doch nichts damit zu tun, wie sie in der Software gespeichert sind.
 
M

MiMa

Ich habe in meinem Modell auch nur drei "Typen", nämlich Datei, Dateityp und Dokumentart. Alle anderen Klassen erben davon.
[/QUOTE]
Dann habe ich das immer noch nicht kapiert :(
 
M

MiMa

Du sprichst hier aber davon, wo oder wie die Daten in der eigentlichen Datei gespeichert sind, oder?

Das hat doch nichts damit zu tun, wie sie in der Software gespeichert sind.
Doch hat es, denn die Methoden zur Speicherung der Daten in ein PDF unterscheiden sicher erheblich als das schreiben der Daten in eine doc.
Wenn ich die Daten nicht in die Datei schreiben würde, dann müsste ich die Klasse des Dateitypen "pdf, doc,.." nicht benötigen, denn nur dort stecken die entsprechenden Methoden um die Daten in die Datei zu schreiben.
 
Thema: 

Vererbung und Komposition??

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben