Private statische Hilfsmethoden

temi

Top Contributor
Mal eine kleine Frage an die Spezialisten.

In einer Klasse könnte man Hilfsmethoden, die den Zustand der Klasse nicht ändern (und auch keinen Zugriff auf den Zustand benötigen) statisch gemacht werden.
Java:
class Foo {
   
    private static int doSomething(int a, int b) {
        // ...
    }
}

Dafür spricht, dass man damit einem Leser des Codes eindeutig signalisiert, dass diese Methode vom Zustand der Klasse unabhängig ist und diesen auch nicht ändert.

Hat das neben diesem Aspekt noch einen Einfluss auf die Ausführung in der JVM? Ich nehme an, nein.

Gibt es sonst noch etwas dazu zu sagen? Pro und Kontra?
 
Zuletzt bearbeitet:

LimDul

Top Contributor
Gefällt mir nicht. Kann ich zwar nicht begründen, aber gefällt mir nicht :)

Ich finde es irgendwie unschön eine Methode statisch zu machen, nur weil sie nicht den Zustand der Instanz braucht, sie aber immer nur im Kontext einer nicht statischen Methode aufgerufen wird und - in 99% der Fälle - auch nur in dem Kontext Sinn ergibt.

Ist mehr Bauchgefühl als konkretes Argument
 

Barista

Top Contributor
K

kneitzel

Gast
Also diesen pauschalen "Nein" Antworten kann ich nicht zustimmen!

Es gibt ein paar gravierende Unterschiede - was mir so auf Anhieb einfällt:
a) Binding: Bei static Methoden hat man ein statisches oder auch early Binding. Im Gegensatz zu Instanzmethoden, die eine runtime / dynamic binding haben.
b) Hier geht es um eine private Methode - aber spätestens wenn ich davon mal was ableite oder so: Da kommen massive Änderungen dazu. statische Methoden kann man nicht überschreiben (Hängt halt mit von a) ab.
c) Von der Schreibweise beim Aufruf: Bei einer Statischen Methode würde ich immer Klassenname.methodenName(...) schreiben, damit auch beim Aufruf klar ist, was da aufgerufen wird.
d) Code Maintenance -> Wenn es nicht statisch ist, dann hat man viel mehr Optionen um es anzupassen.

Ich würde mir auch die Design Frage stellen: Was machst Du in der Methode denn genau? Wenn es unabhängig von der Instanz ist, dann gehört es evtl. auch nicht zur Klasse. Gehört es nicht evtl. woanders hin?

Ich würde es somit nicht pauschal beantworten sondern von Fall zu Fall entscheiden, was wirklich Sinn macht oder eben nicht. Ich würde aber auch mehr zu @LimDul tendieren und es eben nicht sofort statisch machen. (Und das trotz der Prägung durch C#/.Net - da wurde einem sowas um die Ohren gehauen von der statischen Code Analyse und Tools haben das einem auch direkt angedeutet beim Schreiben :) So Methoden sollten dann statisch sein.)
 

temi

Top Contributor
Danke für die interessanten Antworten.

Bei SO ist es eine Meinung, damit dem Programmierer die Unabhängigkeit vom Zustand der Klasse anzuzeigen. Ich verstehe aber auch die Argumente dagegen.
c) Von der Schreibweise beim Aufruf: Bei einer Statischen Methode würde ich immer Klassenname.methodenName(...) schreiben, damit auch beim Aufruf klar ist, was da aufgerufen wird.
Hier sagen zumindest die Code Conventions, dass dies so in Ordnung ist (aber das kann ja auch ein alter Bug sein ;) )
https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html

statische Methoden kann man nicht überschreiben
Kann ja sinnvoll sein, aber das sagst du ja auch am Ende: Kommt drauf an...

Bei static Methoden hat man ein statisches oder auch early Binding.
Worauf hat das Einfluss? Speicherbedarf? Ausführungsgeschwindigkeit?
 

Neumi5694

Top Contributor
Hab's nie wirklich getestet, aber wie schaut es mit Parallelität aus? Wenn die selbe private static-Methode mit einer gewissen Laufzeit in 2 verschiedenen Instanzen der Klasse aufgerufen wird? Kommen sich die beiden in die Quere oder wird auch ohne "synchtonized" brav gewartet?
 
K

kneitzel

Gast
Hier sagen zumindest die Code Conventions, dass dies so in Ordnung ist (aber das kann ja auch ein alter Bug sein ;) )
https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html
Ja, Das wirkliche NO GO ist wirklich der Aufruf auf einer Instanz. Eigene statische Methoden aufzurufen ist so tatsächlich üblich. (Den Fall habe ich ja Java einfach zu selten. Daher hatte ich mich da kurz verwirren lassen beim Schreiben des Punktes.)
Worauf hat das Einfluss? Speicherbedarf? Ausführungsgeschwindigkeit?
Das statische Binding ist dürfte schneller sein. Aber ist hier nicht relevant, denn private Methoden haben auch eine statische Bindung. Der Unterschied ist ja, dass der Compiler direkt sagt: hier wird diese bestimmte Methode aufgerufen. Bei der dynamischen Bindung muss zur Laufzeit geschaut werden: Was haben wir genau für ein Objekt um dann die Methode zu bestimmen.
Hab's nie wirklich getestet, aber wie schaut es mit Parallelität aus? Wenn die selbe private static-Methode mit einer gewissen Laufzeit in 2 verschiedenen Instanzen der Klasse aufgerufen wird? Kommen sich die beiden in die Quere oder wird auch ohne "synchtonized" brav gewartet?
Es wird ohne synchronized nie gewartet aber das Ergebnis ist in beiden Fällen gleich. Denn die lokalen Variablen und Parameter liegen ja auf dem Stack und die sind für jeden Thread unterschiedlich.
 

Barista

Top Contributor
Hab's nie wirklich getestet, aber wie schaut es mit Parallelität aus? Wenn die selbe private static-Methode mit einer gewissen Laufzeit in 2 verschiedenen Instanzen der Klasse aufgerufen wird? Kommen sich die beiden in die Quere oder wird auch ohne "synchtonized" brav gewartet?
Wenn die statischen Methoden nur auf ihren Parametern arbeiten sind sie von vornherein threadsicher, es sei denn, die Parameter sind thread-shared Objekte.
 

Neumi5694

Top Contributor
@ Kneitzel, @ Barista
Danke. Hatte aus Urzeiten noch in Erinnerung, dass lokale in der Methode deklarierte Variablen (Zähler z.B.) nicht in einem Extra-Stack gespeichert würden, aber das trifft heute wohl nicht mehr zu. Außerdem bin ich damals geradce erst von BASIC nach Pascal umgestiegen, also keine wirkliche Java-Angalegenheit :)
 

LimDul

Top Contributor
Nach mal was drüber nachdenken ein paar weitere Gedankensplitter von mir.
Dafür spricht, dass man damit einem Leser des Codes eindeutig signalisiert, dass diese Methode vom Zustand der Klasse unabhängig ist und diesen auch nicht ändert.
Ist das eine relevante Information, die was bringt? Ist diese Aussage überhaupt korrekt?

Technisch ist sie korrekt - sie kann nichts am Zustand ändern.
Aber fachlich? Bei einer privaten Methode?

Macht die Methode genug, um fachlich eine eigene - ich sag mal Identität - zu haben? Sprich ist diese Methode, wenn ich mir diese Methode alleine ansehe, für sich verständlich und sinnvoll?

Wenn ja, kann ich mir die Frage stellen: Warum gibt es für sie keine eigenen Unit-Tests? Gehört die dann überhaupt so als private Methode wohin oder hätte sie dann nicht ihren eigenen Platz mit eigenen Tests verdient? (Und dann kann sie auch gerne statisch sein)

Oder ist es nur eine Methode, die nur im Kontext ihres Aufrufers fachlich einen Sinn ergibt. Und der Aufrufer arbeitet auf der Instanz. Dann ist diese statische Methode ohne die zugehörige Instanz fachlich nicht sinnvoll und damit arbeitet sie zwar technisch nicht auf einer Instanz, aber fachlich schon. Und dann sehe ich den Mehrwert dieser Information nicht - eher im Gegenteil, mir wird etwas suggeriert, was eine rein technische Information ist, die aber der fachlichen Information widerspricht.
 

Neumi5694

Top Contributor
Falls es um die reine Lesbarkeit geht und darum, klassenabhängige Methoden von unabhängigen zu trennen, kannst du dir auch eine interne Utility-Klasse erstellen und die Methoden dort ablegen. Damit ist die Trennung noch deutlicher. Im Normalfall ist das bei anständig gewählten Methodennamen aber nicht notwendig.

Allgemein nutzbare Utility Methoden, die du immer wieder brauchst und immer wieder neu schreiben müsstest, gehören eh in eine eigene Klasse (dann natürlich public).
 
K

kneitzel

Gast
Ist das eine relevante Information, die was bringt? Ist diese Aussage überhaupt korrekt?
Also die Information ist - was die Methode angeht - prinzipiell korrekt. Wenn da bei der Methode static steht, dann ist das ein direkter Fakt.

Aber bei den Aufrufen sieht man das schon einmal nicht. Der Aufruf sieht immer gleich aus (So Du es nicht auf dem Klassennamen aufrufen solltest).

Aber relevant? Sehe ich so nicht. Zum einen sollte jede Methode klar und einfach überschaubar sein und auch entsprechend benannt sein. Vom Methodenname sollte also schon klar sein, was diese Methode macht. "Nebenwirkungen" sollten nicht da sein.

Thema Testbarkeit ist dann auch so eine Sache: Hast Du irgend ein Beispiel, wo das so der Fall ist. Was könntest Du machen, dass
- spezifisch für die Klasse ist (Daher gehört es nur in diese Klasse)
- für alles außerhalb uninteressant (private)
- und unabhängig von jedem Status ist (static)

Und das Thema Testbarkeit kommt dann auch stark zum tragen. Das hast Du erkannt. Eine gewisse Komplexität kann da also auch nicht enthalten sein!
 

Barista

Top Contributor
Macht die Methode genug, um fachlich eine eigene - ich sag mal Identität - zu haben? Sprich ist diese Methode, wenn ich mir diese Methode alleine ansehe, für sich verständlich und sinnvoll?
Die meisten Stilvorgaben verlangen das Auslagern von Code in Methoden.
Jetzt kommst Du und verbietest eventuell das Auslagern von Code in Methoden.
Soll ich jetzt lachen oder weinen?
 

LimDul

Top Contributor
Die meisten Stilvorgaben verlangen das Auslagern von Code in Methoden.
Jetzt kommst Du und verbietest eventuell das Auslagern von Code in Methoden.
Soll ich jetzt lachen oder weinen?
Nein - da hast du mich falsch verstanden.

Das Auslagern ist richtig und wichtig. Aber oft sind die ausgelagerten Methoden nur im Kontext ihres Aufrufers relevant und sinnvoll (und deswegen oft auch private). Das heißt, diese Methode ist ohne ihren Aufrufer "nicht sinnvoll". Und in dem Kontext hinterfrage ich, ob ich dann mit der Information, die mir das static bringt überhaupt was anfangen kann. Oder ob die mich nicht auf eine falsche Fährte führt und die fachliche Verbindung die diese Methode mit ihrem Aufrufer hat auf der technischen Ebene verschleiert.

Nachtrag: - Deswegen hatte ich auch Gedankensplitter drüber geschrieben - zu der eigentlichen Frage hab ich keine belastbare Aussage sondern nur eine Meinung, die auf gewissen Fragmenten, Gedanken basiert - die aber auch nicht vollkommen ausgegoren oder belastbar sind. Ich finde das ein interessantes Thema zum diskutieren, was eher in Real Life als in Schriftform gehen würde. Weil in Schriftform solche Missverständnisse leichter auftreten.
 

LimDul

Top Contributor
Also die Information ist - was die Methode angeht - prinzipiell korrekt. Wenn da bei der Methode static steht, dann ist das ein direkter Fakt.
Auf technischer Ebene ja, auf fachlicher wage ich es zu hinterfragen.

Ich mach mal - ein sehr künstliches Beispiel

Java:
public class Auto {

private static boolean ablendlichtBeiAutomatikEinschalten(Lux umgebungshelligkeit) {
// Mache irgendwelche Berechnungen
}

public void schalteAblendlichtEinWennNotwendig() {
SchalterStatus status = getSchalterStatus();
switch (status) {
case OFF:
  setAblendlicht(false);
  break;
case ON:
  setAblendlicht(true);
  break;
case AUTOMATIK:
  setAblendlicht(ablendlichtBeiAutomatikEinschalten(getLichtSensor().getLux());
  break;
}
}

Dese Methode ist zwar statisch, arbeitet aber impliziert doch auf der Instanz - weil sie Werte von der Instanz als Parameter bekommt und Rückgabewerte direkt in die Instanz geschrieben werden.

Dementsprechend wäre ich dafür:
* Entweder die Methode ist nicht statisch (und dann könnte man sie refaktoren, dass sie direkt selber auf den Lichtsensor zugreift)
* Oder in der Methode passieren irgendwelche Berechnungen bzgl. Helligkeit und Co, die etwas komplexer sind - dann sind das aber Dinge, die vermutlich nichts als private static in der Klasse Auto zu suchen haben, sondern vielleicht in eine Klasse gehören die die Mathematik bzgl. Helligkeitsberechnungen und Co macht.

Ob das wirklich so relevant ist was ich schreibe - keine Ahnung :) Aber da rührt mein Bauchgefühl her, dass ich eher Denke:
* Entweder die Methode gehört woanders hin
* Oder das static fühlt sich falsch an - nach einem Code Smell, dass da irgendwas seltsam ist.
 
K

kneitzel

Gast
Das Beispiel zeigt sehr schön: Es nutzt auf jeden Fall den Lichtsensor der Instanz. Warum hast Du das in einen Aufruf bei dem Parameter gesetzt?

Ich bin schon kein zu großer Fan, mehrere Dinge in einer Zeile zu machen. Wäre hier also schon so ein Ding.

Aber bei dem Beispiel sind die Grenzen falsch gezogen worden. Wo sind denn welche Zuständigkeiten?
- Auf der Instanz muss geprüft werden, wie das Licht aussieht. Also die Methode muss dann nach dem Sensor schauen ...
- In der Instanz sind dann ggf. Parameter konfiguriert bezüglich Grenzwerte.
==> Dann kann evtl. eine statische Hilfsmethode entscheiden: Sind Grenzwerte unterschritten oder nicht.

Natürlich kann man da vieles universeller gestalten. Man kein LichtSensor Interface haben. Dann gibt es aber eine Automatik -> Eigene Klasse! Dabei ist egal (für die Diskussion hier), ob Utility Klasse (Dann bekommt diese einen Lichtsensor und Grenzwerte bei jedem Aufruf) oder ob man eine Instanz erzeugt und dann auf der Instanz Aufrufe macht. Egal wie: Es kommt auf jeden Fall erst einmal etwas dabei raus, das public ist und damit auch Testbar! Und unabhängig von der eigentlichen Diskussion kann man hier auch schon sehen: Eine Modellierung mit Objekten ist auf jeden Fall möglich und statische Helfermethoden wohl unnötig.
 

mihe7

Top Contributor
Dafür spricht, dass man damit einem Leser des Codes eindeutig signalisiert, dass diese Methode vom Zustand der Klasse unabhängig ist und diesen auch nicht ändert.
Nur im Fall von Parametern primitiven Typs. Ansonsten kann man da durchaus Schweinerein betreiben:

Java:
public class Switch {
    private boolean turnedOn;

    public void turnOn() {
        Switch.turnOn(this);
    }

    static void turnOn(Switch s) {
        s.turnedOn = true;
    }
}
 

temi

Top Contributor
Vielleicht noch kurz, wieso ich darauf gekommen bin. Ich habe nach Hashing in Java gesucht und bin über diesen Beitrag gestolpert:

https://www.baeldung.com/sha-256-hashing-java

Da ist die Methode bytesToHex() statisch und daraufhin habe ich begonnen darüber zu sinnieren. ;)

Sollte ich das machen? Warum sollte ich das machen? Warum sollte ich das lieber nicht machen?

Bei SO bin ich dann als erstes über die obige Aussage gestolpert. Ich kann aber alle Argumente dagegen verstehen und auch die generelle Sinnhaftigkeit bezweifeln.
 
K

kneitzel

Gast
Vielleicht noch kurz, wieso ich darauf gekommen bin. Ich habe nach Hashing in Java gesucht und bin über diesen Beitrag gestolpert:

https://www.baeldung.com/sha-256-hashing-java

Da ist die Methode bytesToHex() statisch und daraufhin habe ich begonnen darüber zu sinnieren. ;)
Bei dem konkreten Beispiel sieht man doch direkt, dass es so eben nicht sein sollte.
Das ist doch eine typische Hilfsfunktion. Bytes als hex String anzeigen -> Top Hilfsfunktion.
Und als solche kann (sollte) sie natürlich auch getestet werden.

Aber das ist halt ein typisches Beispiel in einem Blog. Es wird sich lediglich auf den Sachverhalt konzentriert. (Wobei ein public statt private da schon Sinn machen würde)
 
K

kneitzel

Gast
Also "meine" Hash-Klasse würde das auch nicht öffentlich machen. Nur für das Testen, ist da kein ausreichender Grund dafür.
Ja, wenn Du sowas in DEINE Hash-Klasse packen würdest, würde ICH das auch garantiert nehmen und Dir massiv um die Ohren hauen.

Java:
private static String bytesToHex(byte[] hash) {
    StringBuilder hexString = new StringBuilder(2 * hash.length);
    for (int i = 0; i < hash.length; i++) {
        String hex = Integer.toHexString(0xff & hash[i]);
        if(hex.length() == 1) {
            hexString.append('0');
        }
        hexString.append(hex);
    }
    return hexString.toString();
}

Der Code ist in keiner Weise Hash-Klassen spezifisch. Gehört da also ganz offensichtlich nicht rein.

Des Weiteren ist es eine universelle Sache. Es wird einfach nur ein byte Array in einen visuellen String mit HEX-Werten umgewandelt. Das ist also eine typische Sache, die an vielen Stellen verwendet werden kann - halt immer, wenn man genau dies braucht. Also ist das etwas, das tatsächlich public sein sollte. Eine OO Modellierung sehe ich da aber auch erst einmal nicht, daher wäre es schlicht etwas für eine Utility Klasse (in meinen Augen).

Aber ich packe Code, der nichts mit meiner Klasse zu tun hat, eben nicht in meine Klasse. Weder public noch private (in der Hoffnung, dass niemand sieht, was ich mir zusammen frickel oder wie sollte man das umschreiben?)
 

LimDul

Top Contributor
Also "meine" Hash-Klasse würde das auch nicht öffentlich machen. Nur für das Testen, ist da kein ausreichender Grund dafür.
Gegenfrage - was ihat die bytesToHex Methode mit der Hash-Klasse zu tun?

Das hat für mich nix damit zu tun, dass eine Funktionalität, die: unabhäng von der Hash Klasse sinnvoll ist und auch an anderen Stellen verwendet werden kann. Man sieht in dem von der verlinkten Beispiel schön, dass die Verwendung der bytesToHex Methode - egal welchen Algorithmus ich verwende - gleich ist. Und deswegen ist die Methode prädestiniert dafür woanders hingelegt zu werden, wo sie generell genutzt werden kann. Und damit ist dann auch automatisch die Testbarkeit gegeben.
 
K

kneitzel

Gast
Ja, wenn Du sowas in DEINE Hash-Klasse packen würdest, würde ICH das auch garantiert nehmen und Dir massiv um die Ohren hauen.
Dazu vielleicht noch die Anmerkung: Das soll kein pers. Angriff sein sondern ist eher als lustiger Spruch gedacht. Merke nur gerade, dass es falsch ankommen könnte.

Generell ist immer die Frage, was für Absprachen das Team hat. Wie will das Team arbeiten? Ich habe da schon viel erlebt und generell kann ich mit vielen Dingen arbeiten. Daher: Die Methode funktioniert auch in einer solchen Hash Klasse. Kein Thema. Möchte auch nicht ausschließen, dass mir sowas passieren könnte: Man macht paar Refactorings und sieht nicht, dass der Code doch eigentlich verschoben werden muss. Das betrifft nicht die Funktionalität.

Also kommen nur rein formellen Dinge zum tragen. Wie will das Team sowas haben? Wenn das Team keine Library (oder mehrere) pflegt und es um ein kleines, übersichtliches Projekt geht: Da spielt es kaum eine Rolle, ob die Methode in einer Hash Klasse versteckt ist oder nicht. Und zur Not hast Du halt ein Projekt, wo diese Methode sich an mehreren Orten versteckt. Ggf. auch unterschiedlich programmiert. Dann gibt es halt ggf. auch kleine Abweichungen in den jeweiligen Methoden. Die Welt geht nicht unter. (Meiner Meinung nach wird der Code aber schwerer wartbar.)

Aber wenn es darum geht, dass man als Team keinen Doppelten Code will, dass das Team halt die Vorteile erkannt hat und sagt: so und so soll es sein: Dann wird das ggf. zum Problem da es schlicht auffällt und geändert werden muss.
 

LimDul

Top Contributor
Generell ist immer die Frage, was für Absprachen das Team hat. Wie will das Team arbeiten? Ich habe da schon viel erlebt und generell kann ich mit vielen Dingen arbeiten. Daher: Die Methode funktioniert auch in einer solchen Hash Klasse. Kein Thema. Möchte auch nicht ausschließen, dass mir sowas passieren könnte: Man macht paar Refactorings und sieht nicht, dass der Code doch eigentlich verschoben werden muss. Das betrifft nicht die Funktionalität.
Das ist glaub ich was, was nicht schadet noch mal drauf hinzuweisen - wir machen hier (und auch an anderen Stellen im Forum) oft akademische Diskussion. In der Realität hat man oft nicht die Zeit dafür. Und an jeder Stelle eine Grundsatzdiskussion loszutreten sorgt im Projekt meist auch für schlechte Stimmung auf Dauer :)
 

Barista

Top Contributor
Aber oft sind die ausgelagerten Methoden nur im Kontext ihres Aufrufers relevant und sinnvoll (und deswegen oft auch private). Das heißt, diese Methode ist ohne ihren Aufrufer "nicht sinnvoll". Und in dem Kontext hinterfrage ich, ob ich dann mit der Information, die mir das static bringt überhaupt was anfangen kann. Oder ob die mich nicht auf eine falsche Fährte führt und die fachliche Verbindung die diese Methode mit ihrem Aufrufer hat auf der technischen Ebene verschleiert.
Echt abgefahren.

Sollte ich mal in die Situation kommen oder erfahren, dass jemand wegen einem static den Code nicht verstehen konnte und dadurch das Projekt gescheitert ist, dann erinnere ich mich hoffentlich an dieses Posting und melde mich wieder.
Die Wahrscheinlichkeit liegt aber nicht im Promillebereich, sondern weit darunter.
 

mrBrown

Super-Moderator
Mitarbeiter
Sollte ich mal in die Situation kommen oder erfahren, dass jemand wegen einem static den Code nicht verstehen konnte und dadurch das Projekt gescheitert ist, dann erinnere ich mich hoffentlich an dieses Posting und melde mich wieder.
Falls du jemanden suchst, der @LimDul's Aussagen nicht versteht: Glückwunsch, du hast ihn gefunden ;)

Ein Projekt wird auch nicht scheitern, wenn du jeden Methodennamen mit einer zufälligen Zahl beendest – überflüssige Information, die man erstmal verarbeiten muss, ist es trotzdem. Nicht anders ist es bei static, über das man auch erstmal nachdenken muss.
 

temi

Top Contributor
Um es mit @LimDul s Worten zu sagen: Weil es sich falsch anfühlt. Das ist keine Funktion die diese Hashklasse öffentlich zur Verfügung stellen sollte.
daher wäre es schlicht etwas für eine Utility Klasse
Damit kann ich mich dagegen wieder gut anfreunden.

Gegenfrage - was ihat die bytesToHex Methode mit der Hash-Klasse zu tun?

Nicht viel, aber vielleicht ist es die Anforderung an genau DIESE Hashklasse, dass der Hashwert in dieser Form zurück gegeben werden soll. Dann haue ich den Code in die einzige Methode der Klasse und bekomme als Vorschlag, den Code doch zur Übersichtlichkeit in eine separate Methode auszulagern, weil das viel nicer ist.

Aber das war leider auch nicht die Ausgangsfrage und ich will auch nicht das Beispiel bewerten. Ich hatte mir einfach nur Gedanken darüber gemacht, ob das eine gute oder eine schlechte Idee ist, die private Methode statisch zu machen.

Aber ich gebe zu bedenken: Ich komme gerade aus dem Biergarten und bin derzeit nicht diskussionsfähig. Darum lasse ich es für heute auch mal bleiben. ;)
 
Zuletzt bearbeitet:

mrBrown

Super-Moderator
Mitarbeiter
Um es mit @LimDul s Worten zu sagen: Weil es sich falsch anfühlt. Das ist keine Funktion die diese Hashklasse öffentlich zur Verfügung stellen sollte.

Damit kann ich mich dagegen wieder gut anfreunden.

Aber ich gebe zu bedenken: Ich komme gerade aus dem Biergarten und bin derzeit nicht diskussionsfähig. Darum lasse ich es für heute auch mal bleiben. ;)
Ah, ja in der Hash-Klasse selbst würd ich es auch nicht öffentlich machen (allerdings mit @TestOnly auf package-private setzen zum Testen). Ich würds aber auch einfach rausziehen in eine eigene Klasse.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
G Public oder Private oder Protected Sinn Allgemeine Java-Themen 14
J private and arrays Allgemeine Java-Themen 2
Thallius Warum ist meine private porperty public? Allgemeine Java-Themen 7
J private static final String variable Allgemeine Java-Themen 8
Thallius Wie verstecke ich meinen private Key am besten im Code? Allgemeine Java-Themen 10
N Vererbung Static & private fields - Nicht ganz einfach? Allgemeine Java-Themen 4
L Private Key aus KeyDatei extrahieren Allgemeine Java-Themen 2
C Probleme mit dem Zugriff auf private Methode per reflection Allgemeine Java-Themen 2
C Zugriff auf private Methode per reflection geht nicht mehr Allgemeine Java-Themen 3
G Testcases mit Junit auf private-Methode Allgemeine Java-Themen 7
S private ignorieren Allgemeine Java-Themen 7
Z aus private List<???> list eintrag löschen Allgemeine Java-Themen 4
P Private und public Allgemeine Java-Themen 2
tfa Unit-Tests für private Methoden Allgemeine Java-Themen 25
S In Subklasse auf private Variablen zugreifen Allgemeine Java-Themen 4
A Private-Wert eines Objekts auslesen Allgemeine Java-Themen 9
F Javadoc: @value tag nicht für private fields? Allgemeine Java-Themen 11
G per Reflection auf private Klassenattribute zugreifen? Allgemeine Java-Themen 9
M per reflection private attributsnamen auslesen Allgemeine Java-Themen 3
reibi Aufruf eines private Konstruktors Allgemeine Java-Themen 7
J Java Private Edition? Allgemeine Java-Themen 7
M Stärkerer access-modifier als "private"? Allgemeine Java-Themen 17
F Ein interface und private Methoden? Allgemeine Java-Themen 13
S private Vars in abstrakter Klasse nicht in der Unterklasse? Allgemeine Java-Themen 6
S private Instanzvaribalen bei "Innerer-Vererbung" Allgemeine Java-Themen 9
T ungewollter Zugriff auf private Variablen? Allgemeine Java-Themen 3
S private Methoden benutzen Allgemeine Java-Themen 11
G private vs. public JRE Allgemeine Java-Themen 3
T statische Variable und nicht-statische Methode Allgemeine Java-Themen 2
rentasad Design-Frage - Interfaces, Klassen, statische Methoden Allgemeine Java-Themen 3
P "Overriden statische Methode" Statische Methode die vererbt wird Allgemeine Java-Themen 5
N Threads statische Methoden in Threads Allgemeine Java-Themen 5
M Zeiger auf statische Variable Allgemeine Java-Themen 1
S Kapselung Statische Helper Klassen Allgemeine Java-Themen 5
C Classloading und statische Variablen Allgemeine Java-Themen 2
faetzminator statische Variablen in Interface - Vererbung? Allgemeine Java-Themen 9
D Wann sollte ich statische Methoden und Variablen benutzen? Allgemeine Java-Themen 44
J Statische Variablen, Threadübergreifend. Allgemeine Java-Themen 4
R Statische Klasse: Best practice mit flags (2) Allgemeine Java-Themen 3
N Klasse rausfinden, an der eine statische Methode aufgerufen wurde ? Allgemeine Java-Themen 10
R statische initialisierer Allgemeine Java-Themen 7
S statische Methoden und Vererbung Allgemeine Java-Themen 6
M Zwingen eine statische Methode zu importieren Allgemeine Java-Themen 5
heart_disease Designfrage: Statische Konfigurationsklasse Allgemeine Java-Themen 10
S statische Interfaces..? Allgemeine Java-Themen 6
M Wann Membermethoden, wann statische Utility-Methoden? Allgemeine Java-Themen 24
S Innere Klassen und die statische Methode access$x Allgemeine Java-Themen 5
S Statische Methoden in abstrakte Klassen deklarieren? Allgemeine Java-Themen 17
M Paralleler Zugriff auf statische Methode Allgemeine Java-Themen 5
J Statische Methoden in Interfaces? Allgemeine Java-Themen 10
F Statische Methode in abstrakter Superklasse definieren Allgemeine Java-Themen 4
B Statische Methode? Komisch. Allgemeine Java-Themen 5
G Wann statische Methoden, statische Attributen? Allgemeine Java-Themen 7
G Statische Methoden erzwingen Allgemeine Java-Themen 2
H Zugriff auf statische Variable synchronisieren Allgemeine Java-Themen 4
A [SOLVED] Classpath und statische Variablen Allgemeine Java-Themen 6
S Tiefe Kopie einer Baumstruktur als statische Methode Allgemeine Java-Themen 8
M statische Methode per reflection aufrufen Allgemeine Java-Themen 2
M statische regex und vergleiche oder immer wieder compilen Allgemeine Java-Themen 2
S Statische Methode oder nicht? Allgemeine Java-Themen 5
T in einer statischen Methode ein nicht statische Aufrufen Allgemeine Java-Themen 5
D Statische, generische Methode will nicht. Allgemeine Java-Themen 2
H Zugriff auf statische Methode durch mehrere User Allgemeine Java-Themen 19
S Auf statische Funktionen mit Java Reflections zugreifen Allgemeine Java-Themen 3

Ähnliche Java Themen

Neue Themen


Oben