Private Klassenattribute mit public Methoden schützen
lima-city → Forum → Programmiersprachen → Java
behandeln
code
feld
idee
instanz
laufzeit
message
methode
null
objekt
sender
setter
sichtbarkeit
stil
umgehen
unterklasse
url
vererbung
vorgehen
zugriff
-
Ich wollte mal anfragen, wie es zu werten ist, wenn man Felder private macht und zur Manipulation public final Methoden einsetzt, damit sie in Unterklassen nur so und nicht anders verwendet werden kann. Ist das schlechter Stil, oder sogar ein übliches Vorgehen?
Im Prinzip möchte ich, dass die Klasse Message einen Sender und einen Empfänger hat, der nur einmal zugewiesen werden kann. Allerdings müssen final Klassenattribute ja schon im Konstruktor zugewiesen werden, ich möchte es aber später per Methode machen. Die überprüft, ob der Wert null ist, wenn ja wird zugewiesen, wenn nein wird eine Exception geworfen. Diese beiden soltlen natürlich auch in Unterklassen nur so manipulierbar sein.
Geht das so oder gibts eine standardkonformere Variante? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
He,
ich weiß, glaub ich, was du meinst.
1. Du möchtest mit Getter- und Setter-Methoden arbeiten (in C-Sharp heißen die Dinger Properties)
2. über die Getter- und Setter-Methoden geht das
Hier kommt mal Code
public class Message { //Nach außen nicht sichtbare Variablen private Sender meinSender; private Empfaenger meinEmpfaenger; public Message() { } //Mit den Getter- und Setter-Methoden initialisiert man die Variabeln, dabei kann man bsp. Fehler o.ä. abfangen/behandeln public void setSender( Sender send) { if( this.meinEmpfaenger == null ) { meinSender = send; } } public Sender getSender() { return this.meinSender() } public void setEmpfaenger( Empfaenger empf) { if( this.meinEmpfaenger == null ) { meinEmpfaenger = empf; } } public Empfaenger getEmpfaenger() { return this.meinEmpfaenger; } }
Getter- und Setter-Methoden sind in größeren Projekten Standard.
Schau mal da nach:
http://openbook.galileocomputing.de/javainsel/javainsel_05_002.htm#ixdb670f184c34a4b276852e2526cd7e7c
Viel Erfolg
Beitrag zuletzt geändert: 25.7.2011 18:39:12 von jakarta -
Naja es ist schon etwas mehr gemeint, als nur Getter und Setter. Die Problematik liegt hier in der Vererbung. Die Kindklassen sollen nur diese Getter und Setter von der Superklasse nutzen können, da private nicht für Kindklassen sichtbar ist geht das ja auch ok, aber die Frage ist, ob das unter schlechten Stil fällt.
Damit sozusagen von den Unterklassen keine die Möglichkeit hat das if( sender == null ) zu umgehen. -
Also die Kindklassen von Message könnten in meinem Code die Getter- und Setter-Methoden überschreiben und somit die Kontrollstrukturen umgehen.
Du möchtest, dass die Kindklassen von Message die Getter- und Setter-Methoden nicht überschreiben.
-> Dann musst du die Getter- und Setter-Methoden final setzen.
also so:
public final Sender getSender() { return this.meinSender; }
Meiner Meinung nach ist die Arbeit mit Getter- und Setter-Methoden kein schlechter Code bzw Stil.
Wenn du mit Eclipse arbeitest, werden die Getter- und Setter-Methoden vorgeschlagen, wenn man die Variablen private setzt.
Das muss ja was heißen
-
Jop naja selbst wenn sie sie überschreiben, können sie nicht auf die Felder zurgreifen, jedoch ist mir aufgefallen, dass sie dann ja auch einfach neue Felder deklarieren könnten und dieselben Methoden verwenden könnten, das wäre schon schlecht. Deshalb ist das mit final ne gute Idee.
Ich habe nur bemerkt, dass sehr viel darüber gestritten wird, ob private Felder nun vererbt werden oder nicht. Rein technisch würde ich sagen ja, da sie speichertechnisch noch da sind und von nicht private vererbten Methoden ja aufgerufen werden können, damit ist es ja eine Sache der Sichtbarkeit und nicht der Vererbung. Aber gibt auf beiden Seiten Argumente und Anhänger. -
Also technisch gesehen können pivate Felder nicht vererbt werden, ebenso wie private Methoden.
Da ich gerade an meinem SCJP arbeite hab ich nochmal schnell das Lehrbuch gewälzt, das dazu folgendes sagt:
Inheritance allows a class to be a subclass of a superclass, and thereby inherit public and protected variables and methods of the superclass.
Mit deiner Beschreibung "speichertechnisch" liegst du allerdings nicht ganz falsch, da die Werte der Instanz ja da sind und nur durch die Sichtbarkeit per Polymorphie kontrolliert werden. Allerdings wird erst zur Laufzeit entschieden welche "Version" einer vererbten Methode aufgerufen wird. Im Fall der vererbten und nicht überschriebenen Methode wird die Version der Super-Klasse aufgerufen die dann in der Subklasse den entsprechenden Wert liefert. Der Zugriff auf ein privates Attribut einer Superklasse in einer Unterklasse ist so zusagen nur "virtuell", da sich der Wert des Attributes eigentlich in der Superklasse befindet und die JVM entsprechend entscheidet welche Methode aufzurufen ist. Allerdings weiß ich nicht wie die JVM die Instanzen eines Vererbungsbaumes zur Laufzeit trennt, also ob es sich dabei um eigenständige Objekte handelt oder ob alles in einem Objekt gehalten wird, mit verschiedenen "Layern" sozusagen.
Kenne jetzt zwar nicht deine konkrete Ableitungsstruktur aber als Idee könnte man sich mal das "Decorator Pattern" anschauen, bietet eine flexible Alternative zur Unterklassenbildung. Kommt wie gesagt aber auf das dann was damit genau umgesetzt werden soll.
Beitrag zuletzt geändert: 1.11.2011 22:23:55 von sgm02 -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
