Stärkerer access-modifier als "private"?

Status
Nicht offen für weitere Antworten.

Marco13

Top Contributor
Hi

Eine eher philosophische Frage - aber IMHO nicht so unwichtig wie viele andere philosophische Fragen :wink: :

Wäre es nicht sinnvoll, einen Zugriffsmodifizierer einzuführen, der stärker ist als "private"? Mit "private" kann man festelgen, dass auf eine Variable nur von einer bestimmten Klasse zugegriffen werden darf. IMHO sollte man aber auch festlegen können, dass auf eine Variable nur von bestimmten Methoden zugegriffen werden darf (nämlich z.B. nur von get/set-Methoden).

Die Regel, alle Fields "private" zu machen, wird wohl von niemandem (der verstanden hat, warum man das macht) in Frage gestellt. Aber dadurch, dass man innerhalb der Klasse beliebig auf private Variablen zugreifen darf, werden viele Argumente, die für diese Regel sprechen, ad absurdum geführt.

Mal ehrlich: Wer verwendet denn get/set-Methoden, um innerhalb einer Klasse auf die privaten Variablen zuzugreifen? Eigentlich wäre das sinnvoll, aber solange es nicht durch einen Modifizierer erzwungen wird, macht das natürlich niemand.

Mich würde interessieren, was ihr darüber denkt. Es muß ja nicht gleich in einem JSR ausarten, aber.... wer weiß :wink:

bye
 

AlArenal

Top Contributor
Marco13 hat gesagt.:
Wäre es nicht sinnvoll, einen Zugriffsmodifizierer einzuführen, der stärker ist als "private"? Mit "private" kann man festelgen, dass auf eine Variable nur von einer bestimmten Klasse zugegriffen werden darf. IMHO sollte man aber auch festlegen können, dass auf eine Variable nur von bestimmten Methoden zugegriffen werden darf (nämlich z.B. nur von get/set-Methoden).

Wozu?
Willst du (Klasse Mensch) der Instanzvariable Arm sagen, dass es keinen Zugriff aufs Blut hat? Bööööse ;)

Die Regel, alle Fields "private" zu machen, wird wohl von niemandem (der verstanden hat, warum man das macht) in Frage gestellt. Aber dadurch, dass man innerhalb der Klasse beliebig auf private Variablen zugreifen darf, werden viele Argumente, die für diese Regel sprechen, ad absurdum geführt.

Welche denn und warum?

Mal ehrlich: Wer verwendet denn get/set-Methoden, um innerhalb einer Klasse auf die privaten Variablen zuzugreifen? Eigentlich wäre das sinnvoll, aber solange es nicht durch einen Modifizierer erzwungen wird, macht das natürlich niemand.

Es ist Aufgabe der KLasse ihren eigenen inneren Zustand zu kontrollieren. Wenn ein Programmierer nich twillens oder in der Lage ist dies zu tun, hilft auch kein zusätzlicher Modifizierer. Es liegt in seiner Verantwortung zu entscheiden ob es sinnvoll ist auch private Getter und Setter zu benutzen. Ich persönlich arbeite durchaus auch (aber nicht in jedem Fall) mit solchen Methoden.

Mich würde interessieren, was ihr darüber denkt. Es muß ja nicht gleich in einem JSR ausarten, aber.... wer weiß :wink:

Werd mal weniger philosophisch und versuch mal deine angedeuteten Missstände inhaltlich auszuformulieren. DANN wird hieraus vielleicht ne Diskussion. Aber über Halbgares mag ich nicht tieferschürfend sprechen. Vielleicht helfen dir die notwenidgen Gedankengänge um o.g. Formulierungen aufzustellen dabei herauszufinden, dass es eigentlich keinen Grund zur Kritik am aktuellen Status Quo gibt.
 

thE_29

Top Contributor
Ich verstehe dein Problem (obs Al auch verstanden hat, weiß ich nicht da er was von private get/set Methoden fasselt :bae:)


Es geht im darum, das er anderen Programmieren zwingen will, auch in der eigenen Klasse die get/setMethoden zu nutzen um mitzuprotokollieren/loggen etc..

Imho, wäre die Idee vielleicht gar nicht so schlecht. Weil wennst in nem Betrieb bist mit >20 Programmieren die am gleichen Projekt arbeiten und jeder wurschtelt irgendwie rum und verändert dann die Werte ist es ein bisi schwer rauszufinden, wo was geändert wurde! Nimmt jeder die get/set Methoden (so wie es von einer anderen Klasse gemacht wird) so sieht man das immer recht super ;) (bzw man kann halt in den get/setMethoden loggings oder dgl einbauen)

Java fehlen halt doch noch ein paar Dinge ;) (mir selbst fehlt ja das friend - also das man eine explizit Klasse angeben kann die auch einen Zugriff auf private hat - von C++ noch immer ;))
 

-frank

Bekanntes Mitglied
Marco13 hat gesagt.:
Mal ehrlich: Wer verwendet denn get/set-Methoden, um innerhalb einer Klasse auf die privaten Variablen zuzugreifen? Eigentlich wäre das sinnvoll, aber solange es nicht durch einen Modifizierer erzwungen wird, macht das natürlich niemand.

also seitdem ich erkannt habe, dass änderungen/erweiterungen am code oft viel schneller/einfacher zu lösen sind, wenn man nur die get/set-methoden ändern muss, verwende ich eigentlich überall im code get/set. manchmal wärs vielleicht ganz nett mich dazu zwingen zu können (damit ich es nicht vergesse), aber da lasse ich meine IDE immerhin meckern, dass ich kein "this." vorangestellt habe. das tue ich dann meistens auch nicht mehr, sondern ersetze es durch getXY()..
 

AlArenal

Top Contributor
thE_29 hat gesagt.:
Ich verstehe dein Problem (obs Al auch verstanden hat, weiß ich nicht da er was von private get/set Methoden fasselt :bae:)

..die ich auch in der Tat verschiedentlich nutze :p

Es geht im darum, das er anderen Programmieren zwingen will, auch in der eigenen Klasse die get/setMethoden zu nutzen um mitzuprotokollieren/loggen etc..

Imho, wäre die Idee vielleicht gar nicht so schlecht. Weil wennst in nem Betrieb bist mit >20 Programmieren die am gleichen Projekt arbeiten und jeder wurschtelt irgendwie rum und verändert dann die Werte ist es ein bisi schwer rauszufinden, wo was geändert wurde! Nimmt jeder die get/set Methoden (so wie es von einer anderen Klasse gemacht wird) so sieht man das immer recht super ;) (bzw man kann halt in den get/setMethoden loggings oder dgl einbauen)

Mir persönlich wäre es zuwider wenn man versucht durch Sprachfeatures mangelnder Kommunikation und unzureichendem Projektmanagement entgegenzuwirken und dieses damit noch zu begünstigen - weil man es ja dann so schön hartverdrahten kann.

Wie stellt ihr euch eigentlich vor wie die zig großen Java-Projekte mit den großen Entwicklerteams, welche gerade im Open Source Bereich auch häufig nur übers Netz kommunizieren, funktionieren? Das ist für mich Anhaltsapunkt genug dafür, dass ein solches Feature aus den von euch angeführten Gründen nicht notwendig ist.

Es wird doch nicht einfacher ein guter Java-Programmierer und -Entwickler zu werden, wenn wir die Sprache komplexer machen.

Und außerdem: Wenn ich die Klasse x von Autor A bearbeite und der vorsieht, dass ich die secret Instanzvariablen nur über Getter/setter erreichen kann, was hält mich davon ab einfach das secret durche in private zu ersetzen und die Methoden links liegen zu lassen?

Zu Design by Contract gehört auch irgendwie das Grundvertrauen darin, dass sich andere an den Contract halten...
 

Marco13

Top Contributor
@AlArenal: Das Beispiel mit dem Mensch und Blut und Arm war wohl nicht so ernst zu nehmen. Ansonsten müßtest DU mal genauer ausformulieren, was du damit meinst.

In der FAQ steht ja schön erklärt, warum man alle Fields private machen sollte. Der erste Punkt ist "Schnittstellen Definitionen". Eigentlich gilt ja nur das als "Schnittstelle", was nach außen sichtbar ist, aber das ist zwangsläufig eine Teilmenge dessen, was nach innen sichtbar ist, von daher greift das Beispiel auch hier.

Zum Beispiel mit der "Mathematischen Funktion" aus der FAQ:
Code:
class Function
{
    private float x;

    public void getY() { return f(x); } // Nur im positiven Bereich definiert

    public void setX(float xValue) 
    { 
        if (xValue <= 0) 
        {
            System.out.println("Kreisch!"); // Schreieb, wenn die übergebene Variable nicht positiv ist
        }
        else x = xValue;
    }

}

Alles schön sauber, keiner kann von außen ungültige Werte setzen.

Irgendwann schreibt man aber zum Beispiel(!) eine "reset"-Funktion:

Code:
class Function
{
    private float x;
    ...

    public void reset()
    {
        ...
        x = 0;
    }

Man ruft sie von außen auf, und alles ist in Ordnung. Aber spätestens, wenn man den Funktionswert berechnen will, haut's ihn raus, weil 0 nun mal nicht positiv ist. Das hätte verhindert werden können, wenn man gezwungen gewesen wäre, die setX-Methode zu verwenden, um auf x zuzugreifen.



Am Punkt 2, "Flexibilität", sieht man es noch wesentlich deutlicher. Man hat z.B. eine Klasse mit einer internen Struktur
Code:
class XXX
{
    private List elements = ...

    public void addElement(Object element) { elements.add(element); }
    public void removeElement(Object element) { elements.remove(element); }

    public void someMethod()
    { 
        ...
        elements.add(someObject);
        ...
        elements.remove(someOtherObject);
    }
}
Das ist "eigentlich" sauber. Jetzt stellt man im Nachhinein fest, dass IMMER, wenn eine Element entfernt oder hinzugefügt wird, eine bestimmte Aktion ausgeführt werden soll. (Zum Beispiel (!) eine Logging-Ausgabe. Aber das Problem, dass man während der Entwicklung bemerkt: "Immer wenn A passiert, muss auch B passieren" ist sehr allgemein)

Wenn man nun auch innerhalb der Klasse konsequent die addElement/removeElement-Methoden verwendet hätte, könnte man die nötige Aktion einfach in diese Methoden reinschreiben. Da man aber in "someMethod" beliebig in der Liste "rumpfuschen" kann, muss man
1. jeden Zugriff, der dort schon gemacht wird, anpassen
2. hoffen und beten, dass jeder, der in Zukunft die Klasse erweitert oder verändert mitkriegt, dass er doch bitte nicht direkt, sondern immer nur über die beiden speziellen Methoden Elemente entfernen oder hinzufügen soll.

Es ist Aufgabe der KLasse ihren eigenen inneren Zustand zu kontrollieren. Wenn ein Programmierer nich twillens oder in der Lage ist dies zu tun, hilft auch kein zusätzlicher Modifizierer. Es liegt in seiner Verantwortung zu entscheiden ob es sinnvoll ist auch private Getter und Setter zu benutzen.

"Willens oder in der Lage" ist lustig :lol: Hast du schonmal mit mehreren Leuten an einem größeren Projekt gearbeitet? Solche "Constraints" wie die oben beschriebenen lassen sich zwar prinzipiell in der Dokumentation des Fields 'elements' unterbringen, aber das ist lächerlich im Vergleich zu einer echten Überprüfung dieser Bedingungen zur Compilezeit.

Aber über Halbgares mag ich nicht tieferschürfend sprechen. Vielleicht helfen dir die notwenidgen Gedankengänge um o.g. Formulierungen aufzustellen dabei herauszufinden, dass es eigentlich keinen Grund zur Kritik am aktuellen Status Quo gibt.

Meinetwegen nenn' es "halbgar". Ich bin kein Programmiersprachen-Entwickler, und habe nicht 10 Jahre geforscht um eine neues Programmierparadigma auszuarbeiten. Aber vielleicht helfen dir obige Gedankengänge dabei, zu erkennen, dass sowas stellenweise Sinn machen würde.

Aber das soll ja eine Diskussion sein, und kein "Postulieren von Unzulänglichkeiten des Status quo". Ich bin ja für Gegenargumente offen. Insbesondere, wenn ich das Gefühl habe, dass sich da jemand Gedanken gemacht hat, und nicht nur pauschal zu jedem Satz Fragen stellt, die nur aus jeweils einem Wort bestehen.
 

thE_29

Top Contributor
AlArenal hat gesagt.:
Mir persönlich wäre es zuwider wenn man versucht durch Sprachfeatures mangelnder Kommunikation und unzureichendem Projektmanagement

Nur so ne Frage: Was habtn ihr für nen ProjektManagement?! Die haben bei uns keinen DAU vom programmieren, geschweige den definieren die das man alles per set/get Methoden machen soll... Das ist ja schon tiefergehendes programmieren, was bei den Projektleitern ja nix verloren hat..

Und zwecks dem OpenSource und dem ganzen! Schau dir mal den Tomcat source ein.. Sauber programmiert ist was anderes ;) Und wer sagt den das die User net den Code ohne get/set schicken und die Admins von den Projekten das dann umbauen?!

Und soviele Leute verändern OpenSource SW auch nicht! Zumindest halt keine Leute die keinen Ahnung von der Materie haben.. Die wissen ja das man dies tun muss/soll! (also sich an ein paar perverse Richtlinien halten :bae:)

Außerde wäre ja ein Warning schon genug (muss ja keine Exception oder explizit verboten sein).
So wie deprecated also ein Schlüsseltwort wo der Compiler sagt, man sollte es lieber so machen ;)
 

Wildcard

Top Contributor
Eclipse-Plugin schreiben das wahlweise direkten Zugriff als Warning makiert oder beim Speichern (im clean up) direkten Zugriff durch get/set ersetzt und gut ist :wink:
 

AlArenal

Top Contributor
Das liest sich nach "Sun helft mir bitte, weil meine Mitprogger doof sind und sich nicht an die Vorgaben halten". Da hilft doch auch die beste Sprache der Welt nicht.

Was das Beispiel mit dem Logging angeht: Kann man für sowas nicht AOP nutzen? Ich hab mich damit nie eingehend befasst, mir war aber so als ob...

Das Beispiel mit der 0 ist einleuchtend, es stellt sich konsequent zu Ende gedacht eben nur die Frage wieviel man in die Sprache selbst noch reingießen will um dem Programmierer das Denken und Testen abzunehmen. Ich für meinen Teil halte es eh so, dass ich Parameter auf Gültigkeit prüfe und ggf. ne IllegalArgumentException werfe. Wer Unit Tests schreibt wird auch über evtl. Fehler stolpern, ganz ohne die Sprache erweitern und den Coder knebeln zu müssen. Und da ich in den angesprochenen großen Projekten sowieso Unit Tests schreiben muss.....

Ich kann immerwieder nur Smalltalk als Beispiel anführen. Da ist alles public und es funktioniert dennoch. Für meinen Geschmack hat Java auch einige Unzulänglichkeiten, wenn man die Sprache mal mit Smalltalk, Python oder Ruby vergleicht (die wiederum auch nicht das Rad neu erfunden, sondern vielleicht nur cleverer adaptiert haben) und auch die API hat viele Ecken und Kanten.

Die von dir angeführten Beispiele mögen für sich gesehen das angedachte Feature sinnig erscheinen. Ich bin wie gesagt nur überhaupt nicht der Meinung dass der Effekt, den du dir versprichst (Fehlerquellen reduzieren) durch Bloat der Sprache zu erzielen ist. Und ich, der ich ebenfalls keine Sprachen entwickle, sehe eben das Vorhandensein qualitativ hochwertige komplexer in Java entwickelter Software als hinreichendes Indiz und lebendiges Gegenbeispiel abseits von "Hello World", dass es auch problemlos anders geht.

Was mich vielmehr kratzt ist die vergleichsweise geirnge Effektivität pro Code-Zeile in Java. Ne Datei "vernünftig" einzulesen und zu verarbeiten, zu ändern und abzuspeichern erfordert soviel Code, da kann ich in anderen Sprachen schon fette Anwendungen mit schreiben. Ist für mich auch ein Grund für den Hype um JRuby & Co.
 

AlArenal

Top Contributor
Wildcard hat gesagt.:
Eclipse-Plugin schreiben das wahlweise direkten Zugriff als Warning makiert oder beim Speichern (im clean up) direkten Zugriff durch get/set ersetzt und gut ist :wink:

Das ist viel zu pragmatisch für uns Möchtegern-Philosophen :p
 

Wildcard

Top Contributor
AlArenal hat gesagt.:
Das ist viel zu pragmatisch für uns Möchtegern-Philosophen :p
:wink:
Aber im ernst, ich halte es auch nicht für klug die Sprache für sowas weiter aufzublähen.
Wenn man's haben möchte (und verkehrt ist der Gedanke ja nicht) sehe ich die Lösung aber mehr auf der Tool-Seite.
Soll sich die IDE darum kümmern.
Zur Not mit einem Prä-Prozessor drüberbügeln :wink:
 

AlArenal

Top Contributor
thE_29 hat gesagt.:
AlArenal hat gesagt.:
Mir persönlich wäre es zuwider wenn man versucht durch Sprachfeatures mangelnder Kommunikation und unzureichendem Projektmanagement

Nur so ne Frage: Was habtn ihr für nen ProjektManagement?! Die haben bei uns keinen DAU vom programmieren, geschweige den definieren die das man alles per set/get Methoden machen soll... Das ist ja schon tiefergehendes programmieren, was bei den Projektleitern ja nix verloren hat..

Wir machen irgendwas agiles was sich aus den diversen bekannten Methodiken das eine oder andere rausgezogen hat, was für uns eben funktioniert. Im Code machen wir so viel wie nötig und so wenig wie möglich. Dazu gehört u.a. das Prüfen von Parametern, eine Menge "final" und für nicht triviale Dinge auch private oder protected Getter und Setter, wo es eben angebracht ist. Da wir ein kleines Team sind geht das ohne Ordere Del Mufti. Und in ein paar Wochen gehts sogar ohne mich - ich freu mich schon :D

Und zwecks dem OpenSource und dem ganzen! Schau dir mal den Tomcat source ein.. Sauber programmiert ist was anderes ;)

Du liest zuviel BileBlog :p
Mein Ideale sehen auch anders aus, aber ich bin auch Realist genug zu wissen, dass gewachsene Strukturen eben auch zu ziemlich unhübschem Code als Relikt aus der Vorzeit führen können. Das sehen wir doch prima auch im JDK selbst. Als mal alles irgendwie begann, konnte schlecht jemand 10 Jahre Projekterfahrung mit Java vorweisen...
Auch mein Code ist alles andere als ein durchgehender Quell des Lichts. Ich sah mich auch immermehr als Handwerker denn als Künstler. Wenn man was neues dazustrickt und was ändern muss, macht man es dem aktuellen Kenntnisstand entsprechend, der Rest bleibt gemäß "never change a running system" unangetastet. Die Zeit kann sich auch kaum wer leisten sich zu nehmen, ständig wenn er nen neuen Geistesblitz hat allen Code aller Projekte umzuschreiben.

Und wer sagt den das die User net den Code ohne get/set schicken und die Admins von den Projekten das dann umbauen?!

Keine Ahnung. Weißt du wer das sagt?
Code Audits sind doch nichts schlechtes...

Und soviele Leute verändern OpenSource SW auch nicht! Zumindest halt keine Leute die keinen Ahnung von der Materie haben.. Die wissen ja das man dies tun muss/soll! (also sich an ein paar perverse Richtlinien halten :bae:)

Es ging mir weniger ums ändern drurch Dritte, als um die iegentliche Erstellung und Weiterentwicklung. Das sind bei rennomierten Projekten mittlerweile sicher auch viele, die damit Geld verdienen, aber eben auch viele die es "nur" nebenher machen. Und so nen Klotz wie den Tomcat, um dein Beispiel aufzugreifen, möchte ich nicht mit nem Dutzend Leuten entwickeln müssen, die ich nur übers Netz kommunizieren kann.

Außerde wäre ja ein Warning schon genug (muss ja keine Exception oder explizit verboten sein).
So wie deprecated also ein Schlüsseltwort wo der Compiler sagt, man sollte es lieber so machen ;)

Die kann ich ebenso ignorieren oder in der IDE deaktivieren, wie ich auch Richtlinien ignorieren kann ;)
 

Yzebär

Bekanntes Mitglied
Marco13 hat gesagt.:
Hi

Eine eher philosophische Frage - aber IMHO nicht so unwichtig wie viele andere philosophische Fragen :wink: :

Wäre es nicht sinnvoll, einen Zugriffsmodifizierer einzuführen, der stärker ist als "private"?

Kurz und schmerzlos... es ist nicht sinnvoll! Die Deklaration eines solchen Modifizierers wird viel zu komplex und macht den Code schlechter lesbar. Der begrenzte Zugriff auf Variablen, läßt sich auch einfach durch eine geschickte Klassenhierarchie bewerkstelligen.

Klasse A hat mehrere private Variablen und protected/public Methoden, die diese verändern. Klasse A1 erbt von A und kann nur noch über diese Methoden die Variablen indirekt verändern.

Das Aufrufen von privaten Variablen über Getter/Setter innerhalb der Klasse werde ich nicht machen, wenn keine zusätzliche Logik in den Getter/Setter-Methoden ist. Ein Methodenaufruf kostet nämlich Zeit und Performance und wenn ich an vielen Stellen bloß einen Wert auslesen möchte, werde ich das sicher direkt tun! Innerhalb der Klasse sollte man schon wissen, wie man eine Variable ändern darf.
 

Wildcard

Top Contributor
Yzebär hat gesagt.:
Das Aufrufen von privaten Variablen über Getter/Setter innerhalb der Klasse werde ich nicht machen, wenn keine zusätzliche Logik in den Getter/Setter-Methoden ist. Ein Methodenaufruf kostet nämlich Zeit und Performance und wenn ich an vielen Stellen bloß einen Wert auslesen möchte, werde ich das sicher direkt tun! Innerhalb der Klasse sollte man schon wissen, wie man eine Variable ändern darf.
Das Argument kann man so nicht stehen lassen. Der Compiler/Hotspot-Compiler/JIT-Compiler ist nicht blöd und optimiert dir das locker weg.
Immer getter/setter zu verwenden hat definitiv Vorteile, völlig egal ob da zusätzliche Funktionalität liegt oder nicht. (Vererbung zum Bleistift)
 

Marco13

Top Contributor
@Wildcard: Es geht leider nicht immer nur um get/set-Methoden - d.h. ich bezweifle, dass sich sowas durch ein Plugin automatisieren ließe.

@AlArenal: Die Aussage, dass es (sinngemäß) ausschließlich Sache des Programmierers sei, sicherzustellen, dass alles in Ordnung ist, ist sicher richtig. Ein Prorgammierer kann beliebigen Mist machen, und sein Job ist es, etwas zu machen, was kein Mist ist. Das ändert aber nichts daran, dass bestimmte Konzepte sinnvoll sein können, um die Fehlerzahl (oder auch die nötigen Testfälle) zu reduzieren. Ist jetzt vielleicht nicht sooo ein gutes Beispiel, aber: Ich bin bisher auch gut ohne Generics ausgekommen. Jeder Zugriff auf Collections war mit einem Cast verbunden, und wenn's nicht passte, flog ja eine Exception. Wozu also Generics? Ganz einfach: Es ist schöner, sicherer, sauberer, einfacher, praktischer. Notwendig sind sie aber nicht. Und erst recht nicht, wenn man diszipliniert programmiert.

@Yzebär: Das Aufrufen von privaten Variablen über Getter/Setter innerhalb der Klasse werde ich nicht machen, wenn keine zusätzliche Logik in den Getter/Setter-Methoden ist.
Eines meiner Hauptargumente war ja, dass sich das auch mal irgendwann ändern kann - und dann geht die große Sucherei los, und die Kommentare wie "Please do not modify this variable by hand. Please, please, please". Die Zeit, die ein Methodenaufruf bei Java mit JIT braucht ist meistens vernachlässigbar gering. Und eine Klassenhierarchie, wie du sie beschreibst, ist vielleicht "geschickt", um das besagte Ziel zu erreichen, aber insgesamt dann eher unschön: Wer will schon eine neue Klasse einführen, nur um Zugriffsbeschränkungen einzuhalten?
 

Yzebär

Bekanntes Mitglied
Marco13 hat gesagt.:
@Yzebär: Das Aufrufen von privaten Variablen über Getter/Setter innerhalb der Klasse werde ich nicht machen, wenn keine zusätzliche Logik in den Getter/Setter-Methoden ist.
Eines meiner Hauptargumente war ja, dass sich das auch mal irgendwann ändern kann - und dann geht die große Sucherei los, und die Kommentare wie "Please do not modify this variable by hand. Please, please, please". Die Zeit, die ein Methodenaufruf bei Java mit JIT braucht ist meistens vernachlässigbar gering. Und eine Klassenhierarchie, wie du sie beschreibst, ist vielleicht "geschickt", um das besagte Ziel zu erreichen, aber insgesamt dann eher unschön: Wer will schon eine neue Klasse einführen, nur um Zugriffsbeschränkungen einzuhalten?

Vor Java 1.5 mußte man sich auch typsichere Container oder Listen mit einer Extraklasse "erkaufen". Die zusätzliche Klasse ist kein echtes Argument. Solange man eine klare Struktur hat und dadurch Fehler zur Compile-Zeit entdeckt werden bzw. notwendige Paradigmen eingehalten werden, ist es ein relativ geringer Preis.

Mich würde mal ein konkretes Beispiel interessieren, bei dem du das Gefühl hattest, dieser "neue" Modifier könnte dir helfen.
 

AlArenal

Top Contributor
Marco13 hat gesagt.:
@Yzebär: Das Aufrufen von privaten Variablen über Getter/Setter innerhalb der Klasse werde ich nicht machen, wenn keine zusätzliche Logik in den Getter/Setter-Methoden ist.
Eines meiner Hauptargumente war ja, dass sich das auch mal irgendwann ändern kann - und dann geht die große Sucherei los, und die Kommentare wie "Please do not modify this variable by hand. Please, please, please".

Also wenn ich non-public Modifier gezielt dort nutze, wo ich sie für nötig erachte und jemand meint er müsste unbedingt direkt die Variable anpacken, dann hat er wohl grundsätzlich die Funktionesweise der Variable/Klasse nicht verstanden.

Grundsätzlich macht es keinen Unterschied ob er böserweise an der Vriable popelt und wie in deinem o.g. Beispiel mal flott was auf 0 setzt und sich dann ggf. ne NPE einhandelt, oder ob er einer beliebigen Methode einen unsinnigen Wert übergibt, entgegen der z.B: in der JavaDoc abgelegten Spezifikation.

Stellt sich doch die Frage, ob ich dem Programmierer einen Gefallen tue ihn gewissermaßen vorab von der Vernatwortung zu entbinden sich eingehend mit der Funktionsweise zu beschäftigen (denn der Setter wird schon meckern, wenn was nicht stimmt) und dafür sein Korsett noch enger schnüre, nur um ihm damit Sicherheit vorzugaukeln, die ich aber mit Zwangs-Modifiern auch nicht erreiche. Und ich erreiche sie darum nicht, weil nicht zwingend gesagt ist, dass sie die richtigen Untersuchungen anstellen (oder überhaupt was überprüfen) und in beiden Fällen Fehler eh erst zur Laufzeit (wahlweise des Unit Tests, oder beim Kunden) entdeckt werden.

Und mal ehrlich: Wer solche Zwangsmodofier zum Loggen nutzen möchte, sollte ich Zweifelsfalle mal die Performance Penalty ausrechnen und die womöglich entstehenden Datenmengen. Was beim Austesten einer Idee in einem frühen Stadium noch legitim sein mag wird schnell zum Notbehelf deer, die sich ungerne mit einem Debugger auseinandersetzen.

Und weiterhin gäbe es keine Möglichkeit irgendwen daran zu hindern die Sichtbarkeit der Variable nachträglich zu ändern, oder der Zwangsmodifier auszukommentieren, oder die Warning zu Deaktivieren, oder oder oder.

Das Grundproblem bleibt, dass man nicht wild in Code rumpfriemeln sollte, den man nicht vollends versteht und dafür ist letzen Endes auch der verantwortlich, der ihn ursprünglich mal geschrieben hat und da kann er sich nicht mit aus der Affäre ziehen indem er sagt "aber ich hab doch die Variable secret gemacht". Vielleicht liegts dran, dass mir einfach kein griffiges Beispiel einfallen will / präsentiert wird, wo das defacto wirklich etwas bringt. Bisher hört es sich sehr danach an, als wolle man von hinten durch die Brust ins Auge schießen, während man tatsächlich das Knie trifft....
 

Marco13

Top Contributor
Die (konkreten) Beispiele, die ich gepostet hatte, fand ich eigentlich suggestiv genug. (Und das Logging war vielleicht ZU suggestiv :roll: ). Ich glaube, dass es sinnvoll sein könnte, auch innerhalb einer Klasse sicherzustellen, dass bestimmte Bedingungen für eine bestimmte Variable IMMER erfüllt sind. Aber vielleicht ist es ja einfach Ansichtssache.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
J WARNING: An illegal reflective access operation has occurred, beim Compilieren von JasperReports, was bedeutet das ? Allgemeine Java-Themen 23
Bluedaishi Access violation error Allgemeine Java-Themen 2
T Frage zu Access Modifiers Allgemeine Java-Themen 6
E To count password and username access possibility Allgemeine Java-Themen 10
F Alternative sun.jdbc.odbc.JdbcOdbcDriver (Access Datenbank) Allgemeine Java-Themen 2
B Load Library and use JNA to access Allgemeine Java-Themen 3
S Access Restrictions in Eclipse auf Code beschraenken (und nicht fuer Comments) Allgemeine Java-Themen 2
J Access restriction Allgemeine Java-Themen 5
C Klassen Warning "synthetic access" bei innerer Klasse Allgemeine Java-Themen 15
T access$800 Allgemeine Java-Themen 8
J Nice Office Access und Mac Allgemeine Java-Themen 6
S Concurrency access auf eine Map Allgemeine Java-Themen 6
M Access Frontend als Webanwendung Allgemeine Java-Themen 8
S Innere Klassen und die statische Methode access$x Allgemeine Java-Themen 5
B Access-Befehle werden in der falschen Reiehnfolge ausgeführt Allgemeine Java-Themen 4
timomeinen Access Modifier vor Kompilierung ändern Allgemeine Java-Themen 9
P access denied / policy problem Allgemeine Java-Themen 4
W Daten in Access einfügen über Java Allgemeine Java-Themen 21
H Applet - java.security.AccessControlException: access. Allgemeine Java-Themen 6
D Mit Java Daten aus Access holen und als VCard versenden Allgemeine Java-Themen 3
W Sonderzeichen in Access 97 schreiben Allgemeine Java-Themen 2
J MS Access mit Java ansprechen Allgemeine Java-Themen 3
T Word, Excel u. Access API Allgemeine Java-Themen 2
M Access lässt sich nicht über "exec(command)" start Allgemeine Java-Themen 3
J MS Access-Reports steuerung mit Java Allgemeine Java-Themen 6
G JComboBox mit Werten aus einer Access Datenbank füllen Allgemeine Java-Themen 18
C access control list in java Allgemeine Java-Themen 7

Ähnliche Java Themen

Neue Themen


Oben