Java-Applet: Problem mit Datei-Lese-Zugriff

Bin kurz drübergeflogen.

Habe sogleich einige "Vorteile" entdeckt, die keine sind. (Der Schreiber weist implizit drauf hin, aber nach meinem Gefühl wurde der von M$ gesponsort :D)

Ein Beispiel, was mir in der Zukunft viele C# Leute an den Kopf werfen werden, ich warte schon drauf:

get/set - Methoden (liebevoll getter und setter genannt, ich nenn sie gemeinhin "Akzessoren").

Java: object.getValue() / object.setValue(i);
CSharp: object.Value / object.Value = i;

Der Prof meint, der CSharp-Code wäre besser zu lesen etc. Er hat sicher recht. ABER. Dieses System hebelt doch IMHO das komplette Zugriffsschutzkonzept der OO-Entwicklung aus (public, protected...), das wir OO-Programmers uns jahrelang erkämpfen mussten, um endlich kritische interne Abschnitte vor DAUs schützen zu können.

Weiterhin spielen die Akzessoren bei Java eine sehr wichtige Rolle: nämlich im Zusammenhang mit Beans, dem BeanSDK und der darunterliegenden BeanBox as well as mit EJBs allgemein: Der Reflection-Mechanismus erlaubt das sehr schnelle Auffinden der offenen Membervariablen über das Auffinden der Methoden, deren Namen mit get und set beginnen. Das ist ein wirklich essentieller Punkt, der auch wirklich Sinn macht. Microsoft verfolgt abstrakt gesagt einen ähnlichen Ansatz im COM-Modell über das IUnknown-Interfacing (inkl QueryInterface etc..): gewisse Funktionalitäten werden durch spezielle Signaturen gekapselt !

Finde also nicht, dass dieser Aspekt in der professionellen Entwicklung wirklich einen Vorteil darstellt.

Dann: Enums als Datentyp. Das hat C# von C++ geerbt. Enums sind ne feine Sache - aber man braucht sie nicht wirklich. In Java schreibt man sich ne einfache Klasse, die die Enum-Werte als final static member hat. Trotzdem: eher ein Vorteil von C#.

Die Collections in C# gleichen (!) sogar fast im Namen , aber auf jeden Fall im sinn denen von Java, nur muss man in C# von System.xxx inkludieren und in Java von java.util. M$ verkauft das scheinbar auch den Anfängern als tolles Feature, aber ich seh da auch keinen echten "Vorteil" gegenüber Java, wenn nur die Mutter-packages anders heissen. Die foreach-Funktion ist nur ein weiteres Schlüsselwort - das wird in Java genauso über Iteratoren geleistet, wie in C# auch.

Das Interfacing ist in C# weniger fehleranfällig gelöst - gute Sache (aber hier hat M$ natürlich auf die Erfahrungen aus 5 Jahren Existenz der anderen Seite zurückgegriffen...)

Zeigerarithmetik ist nett für C++ Programmierer, wurde aber in Java seit dem ersten Release Candidate ganz bewusst rausgelassen. Hintergrund: Man _braucht_ sie nicht, wenn man genug Rechenpower hat und intelligent programmiert (Stichwort : garbage collection). Sie sind bei der Entwicklung auf verschiedenen Systemen auch ziemlich gefährlich (Alpha Pointer != x86 Pointer etc.)

Und da der Beitrag schon so lang ist, kommt hier für alle das Fazit des Schreibers von oben genanntem Artikel. Dafür gibts ein dickes ACK.

Zitat

C# bietet als Sprache wenig Neues, setzt aber konsequent auf bewährte Konzepte und kombiniert diese. Durch die reine Objektorientierung, wie sie auch in Java praktiziert wird, bietet sie eine gute Basis für wiederverwendbaren Quellcode. Die Wiederverwendung wird noch dadurch gesteigert, dass in C# geschriebene Programmteile in anderen Sprachen (sofern sie auf .NET basieren) eingebunden werden können. Es ist also nicht die Sprache alleine, sondern die Kombination mit .NET die einen zusätzlichen Mehrwert bietet.
Durch die Ähnlichkeit zu Java ist sie auch für Umsteiger schnell zu erlernen. Java-Entwickler haben aber zur Zeit keinen wirklichen Grund, um auf den .NET-Zug aufzuspringen - ist doch der große Vorteil der Sprache die Plattformunabhängigkeit. Diese steckt bei C#/.NET noch in den "Kinderschuhen".

Es bleibt abzuwarten was die Zukunft bringt - aber man darf gepannt sein, denn Microsoft hat .NET zur Chefsache erklärt und ihre ganze Firmenstrategie darauf ausgerichtet. Schaut man auf Beispiele in der Vergangenheit bedeutet dies für Konkurrenten, dass sie vorbereitet sein sollten.

In diesem Sinne:
"look forward and see sharp!"

Alles anzeigen