Vererbung und Komposition??

MiMa

Top Contributor
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?
 

LimDul

Top Contributor
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

Top Contributor
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.
 

MiMa

Top Contributor
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

Top Contributor
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.
 

temi

Top Contributor
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?
 

MiMa

Top Contributor
@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:

MiMa

Top Contributor
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.
 

fhoffmann

Top Contributor
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).
 

MiMa

Top Contributor
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:

temi

Top Contributor
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.
 

fhoffmann

Top Contributor
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();
    }
}
 

MiMa

Top Contributor
@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.
 

MiMa

Top Contributor
@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:

MiMa

Top Contributor
@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:

fhoffmann

Top Contributor
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.
 

temi

Top Contributor
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.
 

MiMa

Top Contributor
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 :(
 

MiMa

Top Contributor
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.
 

MiMa

Top Contributor
Nicht wirklich, das ist mein zweiter Anlauf das Zeug zu verstehen, denn ich komme da ziemlich schnell durcheinander.
Was ich auf Anhieb verstanden habe ist die Vererbung durch Extend.
Aber irgendwann muss man da mal durch und das ist bei mir aktuell.
 

fhoffmann

Top Contributor
Nicht wirklich, das ist mein zweiter Anlauf das Zeug zu verstehen, denn ich komme da ziemlich schnell durcheinander.
Was du vorhast - tausende Dateien zú bearbeiten, sie zu vergleichen und ggf. umzuwandeln - ist ein grßes Projekt. Wenn du noch nicht einmal die Basics (Vererbung) von Java verstanden hast, wirst du daran scheitern.
Sorry,ich will dich nicht entmutigen sondern nur vor fast unvermeidlichen Frustrationen schützen..
 

MiMa

Top Contributor
Die meisten Methoden habe ich bereits in den letzten 2 Jahren in Java geschrieben und somit auch die Sprache Java, MySQL, XML, kennen gelernt.
Davor habe ich ein Jahr mit Applescript gelernt, was jetzt ohne Mac sinnlos ist.
Jetzt versuche ich es etwas energischer es zu erlernen, denn jetzt ist der Zeitpunkt gekommen wo ich es benötige.
Ich mache das als Hobby in meiner Freizeit und die Motivation ist es zu sehen wie es funktioniert. Ich habe schon viele Methoden programmiert die das machen was sie sollen. Oft lerne ich das was ich gerade benötige. Und wenn es XML ist dann lerne ich halt mal ein paar Monate mal XML.
Zu verstehen wie JavaFX GUI mit FXML und MVC funktioniert und es endlich geschafft hatte es selbst um zu setzten hat zwar auch ein Jahr gedauert, aber jetzt kann ich es einigermassen.

Der Anzahl der Post nach, scheint meine Aktuelle Frage doch nicht so trivial zu sein?
 
Zuletzt bearbeitet:

temi

Top Contributor
Doch hat es, denn die Methoden zur Speicherung der Daten in ein PDF unterscheiden sicher erheblich als das schreiben der Daten in eine doc.
Willst du denn Daten in ein PDF oder DOC schreiben? Ich dachte du möchtest Dateien klassifizieren. Dazu musst du Informationen aus den Dateien lesen, z.B. Dateigröße, Dateiname, MIME-Typ, EXIF-Informationen, usw.

Und genau diese gelesenen Daten, dann anschließend in deiner Software speichern. Demnach hättest du eine Klasse in der die gesammelten Informationen gespeichert werden und für jeden Dateityp (Textfile, JPG, PNG, DOC, PDF, usw.) eine ReaderKlasse, die die gesuchten Informationen aus den Dateien liest.

Ich könnte mir das ungefähr so vorstellen:
Java:
FileInfoReader reader = new CompositInfoReader();

reader.addReader(new PdfInfoReader());
reader.addReader(new DocInfoReader());
reader.addReader(new PngInfoReader());

List<FileInfo> fileInfos; // die gewünschten Daten
for (var f : files) { // alle gefundenen Dateien
    fileInfos.add(reader.getInfo(f));
}
Es gibt für jeden Dateityp einen spezialisierte Klasse. Der CompositReader sammelt diese einzelnen Reader. Danach gibts du jede gefundene Datei an den CompositReader, der diese intern an seine enthaltenen spezialisierten Reader weitergibt. Sollte ein Reader zur übergebenen Datei passen, liest er die gewünschten Daten und gibt diese zurück.

Vorteil wäre, dass es sich einfach für weitere Dateitypen erweitern lässt.

Aber vielleicht habe ich einfach mißverstanden, was du erreichen möchtest.
 

MiMa

Top Contributor
@temi
danke für Deine Info, aber diese Reader habe ich bereits.
Was ich benötige ist das dynamische erstellen von Objekten während der Laufzeit, damit die spezifischen Variablen und Methoden der entsprechenden Dateitypen genutzt werden können.

Mittlerweile habe ich etwas über dynamische Bindung gelesen und muss mal sehen ob dies mein Problem löst.
Im Grunde ist es so das ich für eine gefundene PDF-Rechnung andere Instanzvariabeln und Methoden benötige als eine Doc-Rechnung.
Demnach ist der Inhalt eines Objektes bei pdf anders als bei doc.

Die gefundenen Daten aus den Inhalten der Dateien sind quasi Metadaten und diese schreibe ich in eine MySQL Datenbank und zusätzlich an die richtigen Stellen der Datei damit diese Metadaten aus irgendeinen Grund nicht nochmal erneut ermittelt werden müssen.
 

temi

Top Contributor
Ich hatte mir mal Gedanken gemacht, ein kleines Programm zur Verwaltung einer Sammlung zu schreiben. Das Problem ist ungefähr das gleiche, denn je nachdem was in der Sammlung enthalten ist, sind verschiedene Eigenschaften notwendig, z.B. bei Briefmarken (Land, Datum, Erhaltung, Motiv) und bei Porzellan (Land, Manufaktur, Erhaltung).

Meine Idee dazu, war eine Klasse Item (das Sammelobjekt) und eine Klasse Property (die Eigenschaft). Item enthält eine Map mit Eigenschaften, die variabel zugewiesen werden können. Es soll dem Benutzer möglich sein, für "seine" Sammlung die notwendigen Eigenschaften selbst anzulegen. Vielleicht wäre das ja eine mögliche Richtung für dich.

Ganz grob, um die Idee zu skizzieren.
Java:
class Item {
    private final String name;
    private final Map<Property, String> properties = new HashMap<>();
    
    public void addProperty(Property property, String value) {
        properties.put(property, value);
    }
}

class Property {
    public final String name;
    
    public Property(final String name) {
        this.name = name;
    }
}

Property manufacturer = new Property("Manufacturer");
Property year = new Property("Year");

Item antiqueCup = new Item("Antike Tasse");
antiqueCup.addProperty(manufacturer, "Meissen");
antiqueCup.addProperty(year, "1905");
 

MiMa

Top Contributor
Danke für den Tipp.
Das würde bedeuten, da sich je nach Dokumenttyp wie Rechnung alle Instanzvariablen und Methoden zusammenstellen kann.
Das heißt aber auch das ich ein Pool von Instanzvariablen und einen Pool von Methoden habe aus der ausgewählt werden kann.
Ich denke das dabei die Verwaltung und Erweiterbarkeit stark darunter leidet und auch die Übersichtlichkeit verloren geht??
Aktuell habe ich 215 Methoden die übersichtlich in Klassen gegliedert sind, welche dann aufgelöst werden müssten??
Oder verstehe ich das falsch?

Aktuell durchsuche ich den Inhalt nach einer Dokumentart und wollte nach den Ergebnissen das Objekt rückwärtig zusammen bauen.
Suche Dokumentart, dann ermittelt den Dateityp und baut das Objekt zusammen.
PDF-Rechnung = Datei <-- pdf <-- Rechnung
Word-Rechnung = Datei <-- doc <-- Rechnung

Die alternative habe ich schon vor Monaten gemacht und die wäre den Suchalgorithmus um zu drehen.
Also nicht gleich nach der Dokumentart suchen, sondern erst nach dem Dateityp und vererbe es nach und nach!
PDF = Datei <-- pdf.
In der Klasse PDF würde dann die Suche nach der entsprechenden Dokumentart "Rechnung" statt finden.
PDF-Rechnung = Datei <-- pdf <-- Rechnung
Der Nachteil ist, das ich in jeder DateiTyp Klasse nach der Dokumentart suchen muss.
 
Zuletzt bearbeitet:

temi

Top Contributor
Ich verstehe immer noch nicht, warum der Infosatz einer pdf-Rechnung andere Methoden als der Infosatz einer doc-Rechnung haben sollte. Kannst du mal ein Beispiel nennen?

Ich glaube wir schreiben immer noch aneinander vorbei.
 

MiMa

Top Contributor
1. Die Datei wird untersucht und aus dem Inhalt werden Metadaten ermittelt.
Bei einer PDF-Rechnung sind die Informationen wie bei der Doc-Rechnung genau die gleichen.
PDF-Rechnungen können gescannte Papierdokumente sein oder aus Online Shops die als PDF geladen wurden.
Eine Doc-Rechnung ist in der Regel eine Rechnung die ich selbst an jemanden geschrieben haben kann.
Bei beiden werden die gleichen Daten ermittelt die in einem Objekt Platz finden Datei <-- Rechnung
Die Vererbung wäre recht simpel.
Da ich aber die gefundenen Metadaten nicht nur in meine Datenbank speichere, sondern auch in die Datei direkt einbetten möchte benötige ich spezielle Methoden die meine gefundenen Metadaten in das PDF eingebettet. Das kann mit iText oder pdfBox gemacht werden. Und dazu benötige ich die Klasse pdf welche genau diese Instanzvariablen und Methoden beinhaltet. diese Muss zur Erzeugung des Objektes zwischen der Klasse Datei und der Klasse Dokument gebaut werden. Datei <-- pdf <-- Rechnung
PDF-Rechnung.JPG
Bei einer Doc-Rechnung werden die Informationen anders in die Datei eingebettet und daher sind andere Methoden nötig.
Ich kann da nicht mit iText und pdfBox Methoden arbeiten.
Doc-Rechnung.JPG
Es müssen halt immer andere Objekte zusammengebaut werden die aus den verschiedenen Klassen zusammengesetzt werden müssen.
 

temi

Top Contributor
Ok, verstanden. Aber dazu benötigst du nur ein Pendant zu den oben beschriebenen Readern, eben Writer. Das muss meiner Ansicht nach nicht in den Infosatz (ich nenn das jetzt einfach mal so).

Also:

Du liest eine Datei ein. Ein zum Dateityp passender Reader holt die notwendigen Informationen aus der Datei. Der Infosatz wird erstellt. Soll geschrieben werden (z.B. EXIF), dann wird der Infosatz an einen zum Dateityp passenden Writer übergeben. Fertig.
 

MiMa

Top Contributor
Wenn ich mal genauer darüber nachdenke, hast du recht.
Es wird überhaupt keine weitere Klasse benötigt die in ein Objekt eingebettet werden muss. Lediglich die Methoden zum schreiben in die Datei müssen verfügbar sein.
Ich werde das mal so implemetieren und schauen ob weniger mehr ist und vor allem das Problem löst?
Danke.
 

temi

Top Contributor
Beschäftige dich mal mit SOLID. Hier geht es speziell um das Single-Responsibility-Prinzip.

Durch separate Reader und Writer hast du ein sehr offenes System, dass du Stück für Stück implementieren/testen und um neue Dateitypen erweitern kannst. Im Idealfall musst du für einen neuen Typen nur einen Reader und Writer schreiben und irgendeiner Verwaltungsklasse (z.B. CompositReader) hinzufügen.
 

temi

Top Contributor
Und wenn du noch etwas Zeit sinnvoll investieren magst und es noch nicht getan hast, dann arbeite doch mal das Buch "Entwurfsmuster von Kopf bis Fuß" durch. Das wird dir ganz neue Horizonte eröffnen!
 
Zuletzt bearbeitet:

MiMa

Top Contributor
Danke dir das werde ich machen. Die Kopf bis Fuß Bücher finde ich ganz besondert toll weil dort in Wort und Bild erklärt wird.
 

White_Fox

Top Contributor
Und wenn du noch etwas Zeit sinnvoll investieren magst und es noch nicht getan hast, dann arbeite doch mal das Buch "Entwurfsmuster von Kopf bis Fuß" durch. Das wird dir ganz neue Horizonte eröffnen!
Dem stimme ich zu. Bezüglich Java und Softwareentwicklung allgemein war dies das bisher erhellendste Buch, das ich gelesen habe.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
M OOP PropertyChangeListener - Vererbung oder Komposition? Allgemeine Java-Themen 5
U Vererbung?! Allgemeine Java-Themen 15
temi Problem mit Aufrufreihenfolge bei Vererbung Allgemeine Java-Themen 3
Kirby.exe Vererbung bei Generics Allgemeine Java-Themen 7
L Vererbung Verständnis Probleme Vererbung Allgemeine Java-Themen 2
W Generics + Vererbung Allgemeine Java-Themen 47
M Vererbung mithilfe von Bluej Allgemeine Java-Themen 3
M List -Tableview-Javafx-Vererbung Allgemeine Java-Themen 35
A Vererbung Selbstreferenzparameter Allgemeine Java-Themen 14
D Thema: Vererbung Ober-/Unterklassen Allgemeine Java-Themen 16
D Frage zu Vererbung Allgemeine Java-Themen 5
N Vererbung mit GUI Allgemeine Java-Themen 9
E Vererbung Countable mit Vererbung Allgemeine Java-Themen 6
J 2 Fragen zur Vererbung Allgemeine Java-Themen 5
T Javaklassen und vererbung Allgemeine Java-Themen 32
F Vererbung Allgemeine Java-Themen 5
Neumi5694 Vererbung Restriktive Vererbung Allgemeine Java-Themen 4
A Vererbung Übungsaufgabe Vererbung - Erstellung Klassenhierarchie Allgemeine Java-Themen 1
J Allgemeine Fragen zu Vererbung Allgemeine Java-Themen 1
kaoZ Generics und Vererbung Allgemeine Java-Themen 3
D Problem bei Vererbung abstrakter Klassen Allgemeine Java-Themen 6
D Object nach Vererbung mit Class Object überprüfen Allgemeine Java-Themen 4
T Super Klasse Vererbung Problem :/ Allgemeine Java-Themen 10
L Unabhängige Auslieferung bei Vererbung Allgemeine Java-Themen 20
S MVC - Vererbung Allgemeine Java-Themen 4
C Enums und Vererbung Allgemeine Java-Themen 6
F Google Guice + Generics + Vererbung Allgemeine Java-Themen 5
D Unterschied Vererbung und Polymorphie? Allgemeine Java-Themen 4
K Vererbung ohne Basisklasse zu kennen Allgemeine Java-Themen 20
Da_Tebe ArrayList<xyz> Verschachtelung oder Vererbung? Allgemeine Java-Themen 6
faetzminator statische Variablen in Interface - Vererbung? Allgemeine Java-Themen 9
S OOP Mehrfache Vererbung von abstrakten Klassen Allgemeine Java-Themen 7
G Designfrage Vererbung ja oder nein Allgemeine Java-Themen 9
S equals - Identität ändern bei Vererbung? Allgemeine Java-Themen 5
dayaftereh Vererbung Hilfe Allgemeine Java-Themen 2
D Vererbung, Reflection und automatischer Methodenaufruf Allgemeine Java-Themen 24
A PropertyChangeListener Vererbung Allgemeine Java-Themen 4
P DefaultTreeCellRenderer Vererbung Allgemeine Java-Themen 5
S Objekte die Objekte enthalten: Keine Vererbung Allgemeine Java-Themen 4
J Vererbung bei abstrakten Klassen Allgemeine Java-Themen 2
S Vererbung: Welche Methode wird verwendet? Allgemeine Java-Themen 9
L Checkstyle: Wann ist eine Methode für Vererbung entworfen? Allgemeine Java-Themen 13
S normale vererbung als interface Allgemeine Java-Themen 2
S statische Methoden und Vererbung Allgemeine Java-Themen 6
R Vererbung - doppelte Paint-Methode Allgemeine Java-Themen 4
R Vererbung mit Interface und Abstract Allgemeine Java-Themen 3
B Vererbung bei enums ? Allgemeine Java-Themen 3
W Frage zu Vererbung / konkretes Beispiel Allgemeine Java-Themen 4
F Vererbung von SessionBeans Allgemeine Java-Themen 3
O abstract, privat, Vererbung Allgemeine Java-Themen 29
L Annotations mit Vererbung Allgemeine Java-Themen 4
M Singleton und Vererbung? Allgemeine Java-Themen 45
T Problem mit Vererbung Allgemeine Java-Themen 3
V Vererbung und Schleifen Allgemeine Java-Themen 5
C Comparable + Vererbung Funktioniert nicht? Allgemeine Java-Themen 4
A Ansatz Objektorientierung, Methoden Vererbung Allgemeine Java-Themen 2
D Listen von Generischen Typen inkl. Vererbung Allgemeine Java-Themen 2
D Zugriffsmethode nach Vererbung ändern? Allgemeine Java-Themen 5
S Vererbung in UML Allgemeine Java-Themen 3
T Nochmal Frage zu Vererbung Interfaces etc. Allgemeine Java-Themen 10
Y Gedanken zur Vererbung Allgemeine Java-Themen 7
F Vererbung, Generizität und Collections. Allgemeine Java-Themen 7
G Frage zu statischen Variablen bei Vererbung Allgemeine Java-Themen 15
F Vererbung Allgemeine Java-Themen 5
S Vererbung von mehreren Klassen? Allgemeine Java-Themen 5
C enum und Vererbung Allgemeine Java-Themen 3
K Problem mit Vererbung - Kein wirklicher Nutzen. Allgemeine Java-Themen 10
G vererbung vs benutzung Allgemeine Java-Themen 7
L Vererbung klappt nicht Allgemeine Java-Themen 5
W Probleme mit Arrays und Vererbung ! Allgemeine Java-Themen 5
M vererbung einer "selbst-instanzierungs-klasse" Allgemeine Java-Themen 16
J Vererbung. Allgemeine Java-Themen 8
H Frage zur Vererbung Allgemeine Java-Themen 5
S private Instanzvaribalen bei "Innerer-Vererbung" Allgemeine Java-Themen 9
H Vererbung auch ohne erzeugung einer Instanz möglich? Allgemeine Java-Themen 3
M frage zur vererbung Allgemeine Java-Themen 12
G Generics und Vererbung. Allgemeine Java-Themen 21
M Vererbung von Hashtables Allgemeine Java-Themen 5
C dynamische Vererbung Allgemeine Java-Themen 6
S UML Aggregation / Komposition Allgemeine Java-Themen 11
K UML Komposition in Java Code Allgemeine Java-Themen 4
F Was ist Composition/Komposition? Allgemeine Java-Themen 7

Ähnliche Java Themen

Neue Themen


Oben