Zugriff auf protected Fields = guter Programmierstil?

Diskutiere Zugriff auf protected Fields = guter Programmierstil? im Java Basics - Anfänger-Themen Bereich.
S

Schrello

Hey,

ich möchte gern einmal eure Meinung wissen, ob es ein guter Programmierstil ist in abstrakten (oder allgemein Superklassen) die Felder protected zu deklarieren und aus den Subklassen auf diese zuzugreifen, oder sollten aus den Subklassen auch lieber über Getter und Setter auf die Felder zugegriffen werden? (Die Felder dann natürlich nicht protected deklariert)

Programmiere für das Studium.

Vielen Dank für eure Meinungen,

Marcel
 
T

temi

Wieder mal ein Tipp von Joshua Bloch aus "Effective Java":
Entwerfen und dokumentieren Sie für Vererbung oder verbieten Sie sie.
Das heißt für mich, dass man auch die Fehlverwendung von Oberklassen so gut wie möglich verhindern sollte, was evtl. gegen nicht finale protected Felder spricht. Aber auch mit finalen protected Feldern gibt man Implementationsdetails nach außen, was Änderungen der Basisklasse evtl. erschwert.
 
S

Schrello

Danke...

final ist ungünstig, da die Felder von den Subklassen auch verändert werden müssen.... D.h. es spricht eher für die Verwendung von Getter und Setter.
 
T

temi

Generell gilt auch: Komposition ist der Vererbung vorzuziehen, was der Tipp ja auch implizit bereits aussagt.
 
T

thecain

Ich würde getter nicht einem protected Feld vorziehen. Eine abstrakte Klasse ist ja für Vererbung vorgesehen
 
T

temi

Eine abstrakte Klasse ist ja für Vererbung vorgesehen
Das ist aber nicht zwangsweise eine gute Begründung für ein protected Feld, genauso wie ich oben geschrieben habe, dass protected Felder möglicherweise eine Fehlverwendung begünstigen, aber auf jeden Fall die Kapselung der Klasse verringern.
 
W

White_Fox

Ich sehe das auch so wie temi. Grundsätzlich enge ich die Sichtbarkeit so weit wie möglich ein.

Es ist i.d.R. später kein Problem, die Sichtbarkeit später auszuweiten. Es kann jedoch recht leicht ein Problem werden, die Sichtbarkeit später wieder einzuschränken.

Was gelegentlich mal vorkommen kann, ist, daß die Superklasse Eigenschaften oder Informationen der Kinderklasse braucht. Wenn man z.B. bestimmte Funktionalitäten aus der Superklasse heraus bereitstellen und implementieren will, da 95% des Codes einer Methode in allen Kinderklassen redundant wäre. Dann kann man eine Methode wie protected Object getDifferences(); deklarieren und in dieser die 5% Unterschied auslagern.

Aber wenn die Kinderklassen interne Implementierungsdetails über die Superklasse benötigen, dann würde ich mir mal um die Objektstruktur Gedanken machen, dann scheint die nicht in Ordnung zu sein.
 
T

thecain

Ich sehe den Vorteil nicht statt ein protected Feld ein getter/setter Konstrukt zu verwenden. Wenn die erbende Klasse das Feld verändern soll, warum nicht direkt?

Ich sehe hier den Gewinn nicht wirklich. Aber ich muss auch zugeben, ich habe eine "Java Boilerplate" Abneigung. Das getter/setter Konstrukt von Java ist für mich ein super Beispiel für das. Entstanden durch einen Standard (Java Beans) wird es jetzt von vielen Frameworks erzwungen und oft einfach ohne gross nachzudenken für jede private Field generiert.

Ich widerspreche nicht bei Composition over Inheritance, aber das hat damit ja wenig zu tun.
 
T

temi

Ich sehe den Vorteil nicht statt ein protected Feld ein getter/setter Konstrukt zu verwenden. Wenn die erbende Klasse das Feld verändern soll, warum nicht direkt?

Ich sehe hier den Gewinn nicht wirklich. Aber ich muss auch zugeben, ich habe eine "Java Boilerplate" Abneigung. Das getter/setter Konstrukt von Java ist für mich ein super Beispiel für das. Entstanden durch einen Standard (Java Beans) wird es jetzt von vielen Frameworks erzwungen und oft einfach ohne gross nachzudenken für jede private Field generiert.
Ja, du hast Recht, insofern auch ich den blindwütigen Einsatz von gettern/settern und hierbei insbesondere von settern nicht gut heiße. Der Zustand einer Klasse sollte über fachliche Funktionen geändert werden und nicht dadurch, dass mehr oder weniger direkt Werte gesetzt werden (können).

[edit]
Allerdings ist Java ja nicht alleine, was getter/setter betrifft; auch z.B. C# hat ein ähnliches Konzept. Und ein großer Vorteil von settern ist, das hier zumindest Vorbedingungen geprüft und entsprechend behandelt werden können. Genauso wie bei gettern beispielsweise nur Kopien der eigentlichen Daten herausgegeben werden können.
[/edit]

Was gegen die direkte Veränderung eines Feldes spricht: Durch das Öffentlichmachen eines Feldes wird ein Implementationsdetail preisgegeben. Kommt es später innerhalb der Klasse zu einer Änderung z.B. des verwendeten Datentyps, dann kann das für die benutzenden Klassen zu massiven Problemen führen.
 
Zuletzt bearbeitet:
T

thecain

Der Zustand einer Klasse sollte über fachliche Funktionen geändert werden
Da bin ich bei dir. Ich bin auch dafür, wenn möglich ein Feld private zu halten.

Aber um bei deinem Beispiel zu bleiben, wird der Datentyp geändert, muss der getter angepasst werden, was dazu führt, dass alle Nutzer des getters auch angepasst werden müssen. Man könnte hier jetzt argumentieren, dass der getter jetzt so angepasst werden könnte, dass er diese "Umwandlung" macht. Dadurch handelt man sich aber andere Probleme ein.
1. Man hat zwar getter/setter, aber entspricht nicht dem JavaBeans Standard
2. Man hat eine Art "Compatibility Layer" geschaffen

Meine präferierte Lösung sind Immutable Klassen mit dem Builder-Pattern, Vererbung vermeide ich wenn möglich, da es oft zu besseren Lösungen führt. Wenn ich aber zwischen getter/setter oder protected entscheiden muss, ziehe ich protected vor, wenn die Anforderung ist, dass die erbende Klasse das Attribut sowieso ändern können muss.
 
T

temi

Man könnte hier jetzt argumentieren, dass der getter jetzt so angepasst werden könnte, dass er diese "Umwandlung" macht. Dadurch handelt man sich aber andere Probleme ein.
1. Man hat zwar getter/setter, aber entspricht nicht dem JavaBeans Standard
2. Man hat eine Art "Compatibility Layer" geschaffen
Ja, das würde ich so machen und der JavaBeans Standard wäre mir in dem Fall völlig egal.

Alles was an einer Klasse "public" ist, gehört zur Schnittstelle der Klasse und Schnittstellen sollte man gut planen und selten ändern.

Meine präferierte Lösung sind Immutable Klassen [..] Vererbung vermeide ich wenn möglich [..]
Da stimme ich dir zu, und grob zusammengefasst:
  • Zugriff auf Klassen minimieren
  • Immutable Klassen bevorzugen
  • Komposition der Vererbung vorziehen
  • für Vererbung entwerfen und dokumentieren, ansonsten verbieten
  • Schnittstellen den abstrakten Klassen vorziehen
 
Zuletzt bearbeitet:
Thema: 

Zugriff auf protected Fields = guter Programmierstil?

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben