Warum die verschiedenen NSFileHandle-Varianten und wie werden sie implementiert?

Relativ neu zu Cocoa hier. Diese Frage bezieht sich auf NSFileHandle, aber ich habe das Gefühl, dass die Antwort in einem breiteren Cocoa-Programmierkontext relevant sein könnte.Warum die verschiedenen NSFileHandle-Varianten und wie werden sie implementiert?

Ich frage mich nur:

warum gibt es verschiedene NSFileHandle Konstruktor Aromen (dh: je eine für das Lesen, Schreiben und beides).
wie die Kontrolle des Zugriffs auf diese Dateimanipulationsfunktionen implementiert wird, insbesondere da alle diese Konstruktoren generische (id) zurückgeben, die überhaupt nicht verraten, ob sie vom R/W/RW-Typ sind.

Vielen Dank!

Quelle

2010-12-13 Yahya Cahyadi

1) Da Lesen und Schreiben auf den meisten Betriebssystemen (einschließlich Mac OS X/iOS) zwei getrennte Operationen sind, ist ein Dateihandle, das dies kann, in der Regel nicht in der Lage, das andere zu tun Zugriffstypen.)

2) Wir wissen nicht, wie NSFileHandle implementiert ist. :) Oder vielleicht wissen wir es, aber es ist ein Implementierungsdetail, also selbst wenn wir wissen, sollten wir so tun, als ob wir es nicht tun würden.

Quelle

2010-12-13 19:32:39

Danke Jonathan. Ihre Antworten ergeben für mich Sinn, aber erlauben Sie mir, Frage 2 zu formulieren: Warum nicht den Rückgabetyp widerspiegeln, was das zurückgegebene Objekt tatsächlich ist/tut (zB: ID oder ID )? Wird das einige Regeln/Codierungskonventionen für Konstruktorsignaturen durchbrechen? –

Kurz gesagt, ja, das würde die Kodierungskonvention brechen. Die Codierungskonvention hat jedoch eine logische Basis: Wenn die Rückgabetypen von Convenience-Methoden stark typisiert wären, könnten Unterklassen nicht die gleichen Methodensignaturen verwenden. Betrachte '+ [NSString string]' vs. '+ [NSMutableString string]'. Wenn erstere 'NSString *' anstelle von 'id' zurückgab, konnte letzterer keine veränderbare Zeichenfolge zurückgeben (selbst wenn dies der Fall wäre, würde der Aufrufer es nicht wissen.) –

Aber NSFileHandle hat v/spezifische Convenience-Konstruktoren. Scheint, dass jede Unterklasse, wenn sie sich für eine Unterklasse entschieden hat, immer noch Objekte zurückgeben sollte, die immer noch auf die gleiche Weise funktionieren. zB: da 'fileHandleForReadingAtPath' FH zurückgibt, das nur zum Lesen verwendet wird, könnten wir ein Protokoll (zB 'ReadOnlyFH') haben, und die Methodensignatur könnte dann' + (id ) fileHandleForReadingAtPath: (NSString *) path' sein. Die Unterklasse kann weiterhin die Implementierung des zurückgegebenen Objekts erweitern/ändern. –

Warum die verschiedenen NSFileHandle-Varianten und wie werden sie implementiert?

Antwort

Verwandte Themen