Referenz auf Objekte und deren Inhalte

[MiMa]

In der Vergangenheit habe ich immer Methoden programmiert, bei denen ich Werte mitgegeben habe und falls diese ein Ergebnis erzeugten, wurde es mit Return zurück gegeben.

// Variablendeklaration
dateiObjekt.dateiPfadNameEndung
dateiObjekt.dateiEndung
dateiObjekt.InhaltIstLeer

// Mit Rückgabe
dateiObjekt.dateiEndung = sucheDateiEndung(dateiObjekt)

// Methode
public static String sucheDateiEndung(Datei dateiObjekt) {
String dateiEndung = sucheDateiendung(dateiObjekt.getDateiNameEndung);
return dateiEndung
}

Im Speicher werden Objekte ja Referenziert und es wird demnach auf eine Speicheradresse gezeigt die in der Methode mitgeben wird.
Wäre es denn eine schlechte Idee wenn ich nun nun eine Methode programmiere und direkt mit Get und Set Methoden arbeite anstatt einen Werte zurück zu geben?

// Variablendeklaration
dateiObjekt.dateiPfadNameEndung
dateiObjekt.dateiEndung
dateiObjekt.InhaltIstLeer

// Ohne Rückgabe
fuelleWerteInObjekt(dateiObjekt);
LOG.info("Dateiendung" + dateiObjekt.getEndung);
LOG.info("Inhalt ist Leer" + dateiObjekt.isInhaltIstLeer);

// Methode
public static void fuelleWerteInObjekt(Datei dateiObjekt) {
// sucht die Dateiendung
dateiObjekt.setEndung(sucheDateiEndung(dateiObjekt.getDatei));
// Inhalt ist leer
dateiObbjekt.setInhaltIstLeer = true;
}

Wenn die Methode ohne Rückgabe aufgerufen wird, und die Referenz mit gesendet wird, dann kann auf das dateiObjekt zugegriffen werden.
Somit kann man auch auf die Instanzvariablen verändern und zugreifen.
Nachdem die Methode beendet wird, dann geht die Verbindung zu dem dateiObjekt verloren aber da es eine Referenz war, kann man auf die in der Methode erzeugten Werte dennoch zugreifen??!!
Die Programmierung wäre aber dann nicht mehr nach dem BackBox prinzip.

Letzte Möglichkeit wäre dass dateiObjekt komplett mir den geänderten Werten zurück zu geben.

 

[mihe7]

Wäre es denn eine schlechte Idee wenn ich nun nun eine Methode programmiere und direkt mit Get und Set Methoden arbeite anstatt einen Werte zurück zu geben?

Nein, das ist Sinn und Zweck der ganzen Geschichte: man will mit Abstraktionen arbeiten und nicht mit Werten.

 

[MiMa]

Danke, das würde auch einiges erleichtern.
Ist schon ein Unterschied ob man OOP oder imperativ programmiert.

 

[mihe7]

Danke, das würde auch einiges erleichtern.
Ist schon ein Unterschied ob man OOP oder imperativ programmiert.

Äh, OOP ist imperativ

 

[MiMa]

Ja ich meinte Funktionale Programmierung.
bin heute schon zu lang am PC

 

[kneitzel]

Sicher, das du das meinst? Ich würde das jetzt nicht vermuten. Du meinst evtl. prozedurale, nicht objektorientierte, Entwicklung?

Programmierparadigma – Wikipedia

de.wikipedia.org

Da hat man einen Überblick über die Paradigmen ... mit Unterteilung Imperative und Deklarative Programmierung als erste Unterteilung. Bei dem Deklarativen hat man dann Funktionale und Logische Programmierung.... Und Deine Aussagen aus #1 deuten nicht auf Funktionale Programmierung hin...

 

[mihe7]

Um hierauf auch noch einzugehen:

Wenn die Methode ohne Rückgabe aufgerufen wird, und die Referenz mit gesendet wird, dann kann auf das dateiObjekt zugegriffen werden.
Somit kann man auch auf die Instanzvariablen verändern und zugreifen.
Nachdem die Methode beendet wird, dann geht die Verbindung zu dem dateiObjekt verloren aber da es eine Referenz war, kann man auf die in der Methode erzeugten Werte dennoch zugreifen??!!
Die Programmierung wäre aber dann nicht mehr nach dem BackBox prinzip.

Letzte Möglichkeit wäre dass dateiObjekt komplett mir den geänderten Werten zurück zu geben.

Möglich ist beides. Du kannst ein Objekt um Auskunft bitten oder aber anweisen, etwas "für Dich" zu tun. Letzteres kennt man unter der Phrase "Tell, don't ask". Hintergrund ist, dass man verhindert, Entscheidungen basierend auf den Ergebnissen zu treffen, die Objekte liefern. Diese Vorgehensweise wäre typisch für das prozedurale Paradigma.

In Java kannst Du problemlos Objekte erzeugen und zurückgeben, um die Freigabe des Speichers kümmert sich der Garbage Collector.

 

[MiMa]

Du meinst evtl. prozedurale, nicht objektorientierte, Entwicklung?

Ja genau, das meinte ich.

Da gibt es noch etwas, was ich gerne wissen würde.
Um mehrere Dateien ab zu arbeiten wird läuft das ganze in einer Schleife.
Für Dateien die leer, defekt oder geschützt sind werden direkt verschoben.
Dafür habe ich einen if - else Block, der jeweils mit einem continue endet wenn die jeweilige option ausgeführt wurde.
Die Continue Anweisung bricht dann an dieser stelle ab und macht dann in der Schleife weiter was sehr gut funktioniert.
Da dieser if - else Block größer werden könnte würde ich diesen gerne in eine eigene Methode "aussortieren(..)" auslagern.
Allerdings weis ich nicht ob das funktioniert?
Break bricht eine Switch-Anweisung ab und Continue bricht die aktuell Position ab und macht dann in der Schleife weiter.
Ist es denn überhaupt möglich in einer weiteren Methode ab zu brechen und mit dem nächsten Eintrag in der Schleife weiter zu machen?

Danke
Mi

 

[kneitzel]

Also du kannst in der Methode nicht direkt eine Schleife abbrechen. Es gibt da aber mehrere Lösungsmöglichkeiten:
a) Rückgabewert. Wenn das Ergebnis nicht passt, dann brichst Du halt ab.
b) Exception: Wenn Du eine Exception wirfst, dann kannst Du diese auch außerhalb einer Schleife erst abfangen. Aber hier beachten: Exceptions sind "exceptional", also nicht erwartete Ausnahmen. Aber Du erwartest ja explizit, dass einzelne Dateien korrupt sind. Daher würde ich das als unzureichend ansehen.

Also du kannst sehr wohl etwas machen wie

if (isFileCorrupt(fileInfo))
    continue; // oder break oder was auch immer du wünscht :)

 

[MiMa]

Aktuell sieht es so aus.

 // Schleife für die Verarbeitung der Dateien: ANFANG
        for (File eintrag : dateiListe) {
            Datei datei = new Datei(eintrag);

            // Inhaltsprüfungen für Ausnahme-Dateien
            Datei.ausnahmen(datei);
          
            // Verschieben von leeren, defekten und geschützten Dateien
            if (datei.getGroesseBytes() == 0) {
                // Die Datei wird ins Löschverzeichnis verschoben wenn die größe nicht 0 ist
                LOG.info("Die Dateigröße ist " + datei.getGroesseBytes()
                        + " (Bytes) und enthält daher keine brauchbaren Informationen.");
                Datei.umbenennenVerschieben(datei.getDateiQuelle(),
                        new File(einstellungen.getVerzeichnisLoeschen() + "/" + datei.getNameEndung()), einstellungen.isLeerzeichen());
                continue;
            } else if (datei.isInhaltLeer()) {
                LOG.info("Die Quelldatei besitzt keinen Inhalt und wird in das Verzeichnis ohne Inhalt verschoben");
                Datei.umbenennenVerschieben(datei.getDateiQuelle(),
                        new File(einstellungen.getVerzeichnisOhneInhalt() + "/" + datei.getNameEndung()),
                        einstellungen.isLeerzeichen());
                continue;
            } else if (!datei.isLesbar()) {
                LOG.info("Die Quelldatei ist nicht lesbar und wird in das Löschverzeichnis verschoben");
                Datei.umbenennenVerschieben(datei.getDateiQuelle(),
                        new File(einstellungen.getVerzeichnisLoeschen() + "/" + datei.getNameEndung()),
                        einstellungen.isLeerzeichen());
                continue;
            } else if (!datei.isBeschreibbar()) {
                LOG.info("Die Quelldatei ist nicht beschreibbar und wird in das Geschützte verzeichnis verschoben");
                Datei.umbenennenVerschieben(datei.getDateiQuelle(),
                        new File(einstellungen.getVerzeichnisGeschuetzt() + "/" + datei.getNameEndung()),
                        einstellungen.isLeerzeichen());
                continue;
            } // if-else

            // Datei auf Inhalt prüfen
            ....

 

[kneitzel]

Du kannst natürlich hier die continue weglassen und dafür am Ende noch ein else hinzu fügen.

Und du hast da ja eigentlich schon, dass Du da jeweils eine Methode aufrufst, so man von dem LOG und dem continue absieht.

 

[MiMa]

Ja ich weis die Loganweisungen blähen ganz schön auf aber nachdem alles erfolgreich getestet wurde, kommen die auch wieder raus.
Das ist bei dem Atomisieren bei der Datenbankentwicklung.
Erst hat man einen sehr sehr langen Code, dann lagert man entsprechende aus und hat es manchmal schwer zu erkennen ob es nun gut ist oder nicht.

 

[kneitzel]

Naja, das Logging könnte man ggf. in die Methode verschieben. Generell würde ich das drin lassen, nur den loglevel kann man ja anpassen. Sowas ist als Tracing oder Debugging durchaus nett. Da haben wir bei jeder Methode im Kopf eigentlich ein Log, dass es aufgerufen wurde (mit Übersicht der Parameter) und oft auch eine Zusammenfassung der Ergebnisse.

Dann kann man gezielt Tracing einschalten so gewünscht. Wenn man keinen Zugriff auf Produktionssysteme hat, dann ist das eine sehr gute Methode um nachzuvollziehen, wieso etwas schief läuft...

Aber das nur am Rande. Generell halte ich die nicht für störend.