Überall protected-Member?

Sone

Hi,

hatte letztens eine Auseinandersetzung mit meinem Lehrer über access-specifier in Java. Er benutzt in seinem Code wo es nur geht protected Member.

Ich habe ihn gefragt, wieso denn das, wo er doch extra Getter/Setter dafür angefertigt hat. Bzw. die Kindklassen sollten doch auch für die Member über die Setter/Getter fragen, das wäre doch inkonsistent bei der Datenkapselung. Mein Lehrer meinte, dass Ableiten echt eine, wie soll ich sagen, "krasse" Sache ist, bzw. wenn man ableitet liegt die Verantwortung der Basisklasse ganz in der Hand des Programmierers der ableitet, und man sollte bei Ableitung sehr vorsichtig sein. Ich habe widersprochen.

Wie seht ihr das?

MfG

Bashar

Hast du das überhaupt richtig wiedergegeben? Da lohnt sich doch gar nicht drüber zu diskutieren.

Außerdem haben wir ein Java-Forum, das ist schon ganz einsam.

Sone

Bashar schrieb:

Außerdem haben wir ein Java-Forum, das ist schon ganz einsam.

Na, ich dachte das ist eigentlich eher eine OOP-Angelegenheit und hat weniger mit der Sprache zu tun. Oder wie siehst du das?

Sone

Bashar schrieb:

Hast du das überhaupt richtig wiedergegeben?

So ziemlich. Oder was meinst du?

Shade Of Mine

Sone schrieb:

Bashar schrieb:

Hast du das überhaupt richtig wiedergegeben?

So ziemlich. Oder was meinst du?

Du hast die Aussagen sehr ver-simpelt.

Alles protected zu machen ist dumm. Darueber zu diskutieren bringt nichts. Jeder der von OOD eine Ahnung hat wird dir sagen "Access Levels so restriktiv wie moeglich machen". uU hat dein Lehrer aber etwas anderes gemeint.

Java hat zB Package Level Access Modifier. zB package private ist etwas anderes als private in C++.

Bashar

Sone schrieb:

Bashar schrieb:

Außerdem haben wir ein Java-Forum, das ist schon ganz einsam.

Na, ich dachte das ist eigentlich eher eine OOP-Angelegenheit und hat weniger mit der Sprache zu tun. Oder wie siehst du das?

Java Sichtbarkeiten sind public > protected > default/package > private. In C++ gibts keine Packages, in C# gibts irgendwie noch internal irgendwo dadrinnen. Im Endeffekt bedeutet das, dass die Entscheidung, was man z.B. protected macht oder nicht von der Sprache abhängt.

Sone

Gut, also Java-Angelegenheit.

Vergessen zu erwähnen: Es geht hier um einen Projektcode, nicht um sein Programmieren im Allgemeinen. Mit "Code" meinte ich eben den. (Allerdings habe ich noch keinen anderen von ihm gesehen, und es geht auch mehr um seine Argumentation)

Ich hab mal gezählt. In seinem Projektcode sind 16 von 18 Membervariablen protected (von allen Klassen, die in der main-Applikation mal ausgelassen).
Und er meinte persönlich zu mir, das mache er so weil die/der ableitende Klasse/User volle Verantwortung über die Basisklasse übernehmen soll.

Sone schrieb:

Ich habe ihn gefragt, wieso denn das, wo er doch extra Getter/Setter dafür angefertigt hat. Bzw. die Kindklassen sollten doch auch für die Member über die Setter/Getter fragen, das wäre doch inkonsistent bei der Datenkapselung. Mein Lehrer meinte, dass Ableiten echt eine, wie soll ich sagen, "krasse" Sache ist, bzw. wenn man ableitet liegt die Verantwortung der Basisklasse ganz in der Hand des Programmierers der ableitet, und man sollte bei Ableitung sehr vorsichtig sein. Ich habe widersprochen.

Das eine hat mit dem anderen nichts zu tun.
Einmal redet ihr über access modifier und einmal darüber, wie sinnvoll Ableitungen sind. Da habt ihr/du Sachen vermischt und deswegen klingt deine Wiedergabe auch ziemlich wirr. Aber man kann allgemein antworten:
- Wie schon erwähnt wurde: Access-Levels so restriktiv wie möglich halten.
- Delegation und Interfaces Vererbungen vorziehen (hierzu sind Bücher über Software-Patterns oder Software-Architektur empfehlenswert).

L. G.
Steffo

hustbaer

Alles (oder fast alles) protected machen is plem. Und auch nicht nötig.
Alles private und final machen ist viel besser. (Ausser Dingen natürlich die ganz klar public/protected/internal bzw. non-final sein MÜSSEN, und zwar zu dem Zeitpunkt wo man den Code schreibt - nicht irgendwann vielleicht)

Wenn man in Zukunft mal irgendwo irgendwie Zugriff auf irgendwas brauchen könnte, dann schafft man die Möglichkeit dazu einfach. Und zwar dann wenn man sie braucht, nicht vorher. Dann weiss man nämlich auch schon was man überhaupt konkret machen will, und kann es so machen wie es Sinn macht.
Das selbe für final, wenn man mal was überschreiben will dann macht man das final halt weg - bzw. integriert es so wie es Sinn macht.

Man lässt ja auch net seine Haustür permanent offen weil's sein könnte dass mal irgendwann wer auf Besuch kommt.

hustbaer

Steffo schrieb:

Einmal redet ihr über access modifier und einmal darüber, wie sinnvoll Ableitungen sind. Da habt ihr/du Sachen vermischt und deswegen ...

Also nö, ableiten und protected haben schon recht ziemlich ganz viel miteinander zu tun.

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Java verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Eisflamme

Was heißt hier überhaupt, die ableitende Klasse übernimmt die Verantwortung für die Member. Sie übernimmt zusammen mit der Oberklasse eine geteilte Verantwortung auf, ja. Aber dann können beide die Werte manipulieren und die abgeleitete nicht etwa über Schnittstellen der Oberklasse...

Ich finde, Attribute sollten im Normalfall private sein, außer man hat so viele reine Getter/Setter, dass man darüber nachdenken könnte sie protected zu machen (doch dann vielleicht sogar direkt eine struct und public? Die Diskussion gab es ja letztens mit knivil, wenn ich das gerade nicht verwechsle). Keine Ahnung, was Dein Lehrer da meint.

Edit: Da das jetzt offiziell im Java-Forum ist, diskontiere ich das Gewicht meiner Aussagen individuell für jeden um das Gewicht, welches er der Programmiersprache für die Beantwortung der Frage hier gibt.

hustbaer

Eisflamme schrieb:

Keine Ahnung, was Dein Lehrer da meint.

Ich glaub der is einfach nur doof.
Those who can, do. Those who can't, teach.

Sone

Shade Of Mine schrieb:

Alles protected zu machen ist dumm.

hustbaer schrieb:

Alles (oder fast alles) protected machen is plem. Und auch nicht nötig.

Steffo schrieb:

- Wie schon erwähnt wurde: Access-Levels so restriktiv wie möglich halten.
- Delegation und Interfaces Vererbungen vorziehen (hierzu sind Bücher über Software-Patterns oder Software-Architektur empfehlenswert)

Gut, könnte jemand nochmal auf den Punkt bringen wieso man alle Member nicht einfach aus dem Grund, die ableitende Klasse sollte volle Kontrolle haben, protected macht? Mein Lehrer hält vom Internet nicht viel, da dort auch viel Scheiß steht (ja, ich war dann immer ganz schnell still XD).

Soll ich mal den Projektcode hochladen?

hustbaer schrieb:

Steffo schrieb:

Einmal redet ihr über access modifier und einmal darüber, wie sinnvoll Ableitungen sind. Da habt ihr/du Sachen vermischt und deswegen ...

Also nö, ableiten und protected haben schon recht ziemlich ganz viel miteinander zu tun.

Seine Argumentation war, dass die Klasse volle Kontrolle haben sollte.

Shade Of Mine

Sone schrieb:

Gut, könnte jemand nochmal auf den Punkt bringen wieso man alle Member nicht einfach aus dem Grund, die ableitende Klasse sollte volle Kontrolle haben, protected macht?

Invarianten und Kapselung -> Bertrand Meyer würde ich ihm hier empfehlen.

Diese Diskussion bringt aber nichts. Deine korrekte Reaktion wäre "Ja" und "Amen" zu sagen und dich nicht weiter als notwendig mit dem Professor zu befassen. Du wirst seine Meinung nicht ändern können, du wirst nur negativ bei ihm auffallen und dir dadurch das Leben selber schwer machen.

Sone

Shade Of Mine schrieb:

Deine korrekte Reaktion wäre "Ja" und "Amen" zu sagen und dich nicht weiter als notwendig mit dem Professor zu befassen. Du wirst seine Meinung nicht ändern können, du wirst nur negativ bei ihm auffallen und dir dadurch das Leben selber schwer machen.

Mittlerweile habe ich das Gefühl, Professoren geben einem zwei Optionen...

Vielen Dank für die Bestätigung. Ich werde in Zukunft einfach stumm lächeln wenn er mir (bzw. uns) fragwürdige Sachen vermittelt (und z. T. hier nachfragen ob mein Einwand berechtigt ist ).

Edit: Komisch. Der Link oben ist irgendwie tot.

hustbaer

Sone schrieb:

Shade Of Mine schrieb:

Alles protected zu machen ist dumm.

hustbaer schrieb:

Alles (oder fast alles) protected machen is plem. Und auch nicht nötig.

Steffo schrieb:

- Wie schon erwähnt wurde: Access-Levels so restriktiv wie möglich halten.
- Delegation und Interfaces Vererbungen vorziehen (hierzu sind Bücher über Software-Patterns oder Software-Architektur empfehlenswert)

Gut, könnte jemand nochmal auf den Punkt bringen wieso man alle Member nicht einfach aus dem Grund, die ableitende Klasse sollte volle Kontrolle haben, protected macht?

Hab ich doch schon begründet...
Es ist schlecht, weil man dann ableiten und Unfug anstellen kann.
Und Leute tun das dann auch.
So entsteht Code wo die Basisklasse und die abgeleitete Klasse bösest gekoppelt sind. Eine minimale harmlos aussehende Änderung in der Basisklasse kann dann dazu führen dass die abgeleitete nimmer funktioniert.
Davon die Basisklasse zu refactoren kann man dann nur träumen.

Wenn man dagegen nur ganz selektiv bestimmte Dinge protected macht, und erst wenn es nötig ist, und dabei ganz bewusst darauf achtet nix aufzumachen was einem in Zukunft das Leben zur Hölle machen könnte, dann vermeidet man dieses Problem grösstenteils.

Klar, manchmal kann man nicht anders als viel aufzumachen und Klassen sehr eng zu koppeln. In C++ gibt es dafür friend. In Java gibt es dafür "default" (=das was man bekommt wenn man weder private noch protected noch public hinschreibt). Damit macht man die Klasse zwar gegenüber dem ganzen Package auf, aber wie gross das Package ist kann man ja kontrollieren. Und man kann sicher sein dass nicht irgend ein Depp in einem anderen Team hergeht und damit Scheisse baut.

ps: In Java ist protected zusätzlich zu abgeleiteten Klassen auch für das ganze Package offen. D.h. man hat mit "default" keinen Nachteil, wenn es nur darum geht dass eine Klasse im selben Package Zugriff auf viele "Internas" einer anderen braucht.

Sone

Was mir noch auffällt: Er macht die Koordinaten in einer 3D-Vektor Klasse protected...? Ich meinte, WTF? Die sollten doch erstens public sein, weil solche Vektoren einfache Datenstrukturen sind, und zweitens habe ich noch keine 3D-API gesehen, wo das anders ist (und ich habe schon einige gesehen)... und wer leitet schon von einer Vektor-Klasse ab?

Edit: Bezüglich zur Vektor-Klasse hab' ich noch mal nachgedacht, und mir scheint, als ob das in C++ anders ist weil da solche Vektor-Klassen viel öfter kopiert werden...

Und dann sowas:

for(int n = 1; n<=100000000; n++){
	try {Thread.sleep(10);} catch (InterruptedException e) {}
        // ....

Ich mein, hä? Wieso nicht einfach eine Endlosschleife?

Dein Leerer hat keine Ahnung von dem was er tut. Da brauchen wir nicht lang rumdiskutieren.

otze

hustbaer schrieb:

Hab ich doch schon begründet...
Es ist schlecht, weil man dann ableiten und Unfug anstellen kann.
Und Leute tun das dann auch.

Ja, und dann sagen die Profs: "und genau dafür haben wir das ja auch protected gemacht". Zumindest ist es das, was ich so erlebe. Die Fähigkeit eine Idee spontan innerhalb weniger Minuten in Code umzusetzen wiegt schwerer, als das was softwaretechnisch richtig wäre. Die Annahme ist, dass die Leute wissen, was sie tun uns selbst dafür sorgen, dass die invarianten stimmen. Dafür hat man aber eine einfache Möglichkeit, schnell eine Funktion zu überschreiben. Im Allgeminen macht das keinen Sinn, aber wenn ein Prof das sagt, dann kann das in seiner Anwendung sogar sinn machen.

Kurze gesagt, dein Lehrer braucht ne Nachschulung:) Forum kann geschlossen werden