| 

.NET C# Java Javascript Exception

1
Ich bin gerade am Einsteigen in Objective-C und bin auf der Suche nach den Interfaces wie ich diese aus Java kenne. Habe zwar @interface gesehen und verstanden, aber das ist ja nur das Klasseninterface. Gibt es hier keine Interfaces wie aus Java bekannt?
News:
05.09.2011
Gast
13 4
2 Antworten
3
3
Ist auch kein Wunder, denn Objective-C war der Haupteinfluss für Java (und *nicht* C++ wie oft fälschlicherweise behauptet wird), die Java- und Objective-C-Teams waren eng befreundet und als es mit NeXT bergab ging, wechselten mehrere der Objective-C-Designer zu Sun. Einer der Designer von Java erwähnt explizit Interfaces als etwas, das *direkt* von Objective-Cs Protocols übernommen wurde.
Jörg W Mittag 05.09.2011
1
@Jörg +1 Interessant, das wußte ich noch nicht. Was für ein Glück, dass sie die []-Syntax nicht auch übernommen haben...
Matthias Hlawatsch 05.09.2011
Java Was Strongly Influenced by Objective-C and not C++: http://cs.gmu.edu/~sean/stuff/java-objc.html
Jörg W Mittag 05.09.2011
“Bruce Martin was working on the NeXTStep 486 port, Peter King, Mike Demoney, and John Seamons were working on the mysterious (and never shipped) NRW (NeXT RISC Workstation, 88110???). They all joined us in late ’92–early ’93 after we had written the first version of Oak. I’m pretty sure that Java’s ‘interface’ is a direct rip‐off of Obj‐C’s ‘protocol’ which was largely designed by these ex‐NeXT'ers …”
– Patrick Naughton: Java Was Strongly Influenced by Objective-C and not C++ (http://cs.gmu.edu/~sean/stuff/java-objc.html)
Jörg W Mittag 05.09.2011
1
Es gibt bei protocol einen kleinen Unterschied: In Objective-C kann man das Attribut @optional verwenden um Methoden zu kennzeichnen, die nicht implementiert werden müssen. Soweit mir bekannt gibt es das in Java nicht.
05.09.2011
puls200 3,8k 7
Stimmt, in Java muss man sich die Mühe machen, die Methode durch Werfen einer java.lang.UnsupportedOperationException zu implementieren.
Matthias Hlawatsch 05.09.2011
Eine Implementierung, die eine Unsupported Exception werfen muss, ist für mich ein Indiz für falschen Interface-Zuschnitt bzw. dafür, dass es sich eigentlich um ein anderes (womöglich ähnliches Interface) handelt. Außerdem ist für einen Aufrufer, der das Interface verwendet, die Precondition der Methode womöglich nicht eindeutig und auch nicht nachvollziehbar. Hat dieses @optional einen Sinn, der sich mir gerade nicht erschließen will?
ffordermaier 05.09.2011
Zum einen: sowohl Java als auch .NET machen selbst davon im Framework Gebrauch:

http://download.oracle.com/javase/6/docs/api/java/util/List.html#remove%28int%29

http://msdn.microsoft.com/en-us/library/system.componentmodel.ibindinglist.applysort.aspx

Zum anderen: theoretisch könnte man durch intensives Spezialisieren auf diesen Ansatz verzichten. Aber wenn ich in einem "konzeptionellen" Interface 3 optionale Methoden habe, brauche ich schon 8 spezialisierte Interfaces, um alle Kombination von "wird unterstützt" und "wird nicht unterstützt" darstellen zu können. Das wird bald unhandlich.
Matthias Hlawatsch 05.09.2011
Beide Ansätze (NotImplementedException und @optional) sehe ich rein syntaktisch. Ich finde @optional passt in Objective-C besser weil dort Methodenaufrufe Messages sind. D.h. eine Klasse die eine @optional Methode nicht implementiert reagiert eben nicht auf die Nachricht - fertig.
puls200 05.09.2011
Das geb ich Dir schon recht. Dann muss ich aber eine andere Methode zur Verfügung stellen, die mir erlaubt, exceptionfrei die Precondition der Methode zu prüfen.
Ich bin da eher ein Freund eines weiteren Interfaces. Wenn es wirklich zum ursprünglichen Interface gehört und nicht abtrennbar ist, dann sollten wenigsten Methoden zur Verfügung stehen, mit denen ich die Unterstützung einer "optionalen Methode" prüfen kann (SupportsXYZ). Das ist in meinen Augen im nutzenden Code klarer verständlich, als ExceptionHandler.
ffordermaier 05.09.2011
1
Diese Methode gibt es auch:
if ([irgendeinObject respondsToSelector:@selector(optionaleMethode:)]) {
[irgendeinObject optionaleMethode];
}
Sowas sieht man sehr häufig in Objective-C code. Ob am Ende übersichtlicher oder nicht ist wie immer Geschmacksache ;)
puls200 05.09.2011
Da stimme ich Dir zu. Das ist - genau wie Matthias Aussage auch - Geschmackssache. Solange sich die Teams darauf verständigen und einen einheitlichen Ansatz wählen, ist alles in Ordnung. Ich wollte nicht per se @optional oder UnsupportedExceptions verteufeln, sondern lediglich mit meiner Sichtweise den Meinungsaustausch anregen. Es gibt in meinen Augen nämlich zu wenig Reflektion über für sich selbst etablierte BestPractices. Und mich hat diese Frage auf alle Fälle zur Reflektion meiner eigenen Sichtweise bewegt.
ffordermaier 05.09.2011
Der Austausch hier ist für mich auch das Interessante an Codekicker - die Fragen eher weniger.. ;-) Leider tendieren Kommentare eher unterzugehen obwohl sie manchmal deutlich interessanteren Inhalt haben als Frage & Antwort, siehe auch Jörg's Beitrag oben
puls200 06.09.2011

Stelle deine Mobile-Frage jetzt!