Private Variablen / Methoden in anonymer Klasse?

Ich wäre versucht, sie privat zu machen, nur weil Sie den Code umgestalten und die anonyme Klasse als Standardklasse herausziehen (Intellij zum Beispiel kann dies auf Knopfdruck tun), indem Sie privat sind Felder sind das, was du wirklich willst. Sie müssen Ihre Klassen nicht nach Ihrem Standard anpassen.

Ich persönlich würde sie trotzdem privat machen (und, wenn möglich, final) - es ist nur eine gute Gewohnheit, ganz allgemein dabei zu sein.

Um es anders auszudrücken: Wenn Sie einen Zugriffsmodifikator verwenden wollten (wenn beispielsweise das Schlüsselwort package auch als Zugriffsmodifizierer verwendet wurde), was würden Sie wählen? Privat, vermutlich - schließlich willst du eigentlich keinen anderen Klassenzugang gewähren, oder?

Nachdem ich nun entschieden habe, dass privat der logischste Zugriffsmodifikator ist, würde ich dies im Code explizit machen.

Andererseits würde ich wahrscheinlich auch keine anonyme innere Klasse mit einer Membervariablen erstellen - ich wäre versucht, stattdessen eine benannte verschachtelte Klasse zu verwenden.

Ihr Professor hat Recht. Machen Sie alle Klassenvariable privat und setzen Sie sie über Eigenschaften frei (wenn sie nicht anonym sind).

Die allgemeine Faustregel ist, dass Mitgliedsdaten wie die Variable einschließlich Ihres Kartenobjekts privat bleiben sollen.

Der Standardmodifikator ist nicht derselbe wie der private -Modifikator, es gibt feine Unterschiede. In Ihrem Fall handelt es sich jedoch eher um eine religiöse Frage, ob convert () standardmäßig oder privat sein soll. Ich sehe jedoch keinen Vorteil darin, es privat zu machen.

Wie auch immer, Ihr Code hat ein Speicherleck, da der String Cache niemals gelöscht wird: -P Verwenden Sie für noch weniger / weniger Code den Komparator String.CASE_INSENSITIVE_ORDER :

Es ist wirklich egal, aber es ist wahrscheinlich eine gute Idee, deinen Lehrer glücklich zu halten, wenn er dich benotet.

Ich würde sagen, es ist eine Frage des Stils. Sie können nicht außerhalb der anonymen Klasse auf das Member map outside zugreifen, aber es wäre am besten, sie aus Gründen der Konsistenz mit anderen Klassen als privat zu definieren.

Wenn dies mein Code wäre, würde ich sagen, wenn eine Klasse kompliziert genug ist, um Datenelemente zu benötigen, könnte es sich lohnen, sie in eine separate Klasse zu ziehen. In diesem Fall würde ich die Datenmitglieder sicherlich als privat definieren / p>     

Der entscheidende Punkt ist, wenn Sie sagen: "Ich sehe nicht, wie die Änderung des Modifizierers einen Unterschied macht, da diese Variablen und Methoden für die anonyme Klasse sowieso privat sind" ... Sie nehmen viel an, wie Ihre Klasse ist werde benutzt werden. Behandeln Sie jede Klasse so, als ob sie weitergegeben und auf verschiedene Arten verwendet wird. Verwenden Sie Modifikatoren entsprechend. Außerdem macht es die Absicht der Klasse klar. Es ist sowieso nicht so, dass Java eine knappe Sprache ist, also könntest du genauso gut klar sein.

Ich sehe keinen großen Vorteil darin, die Dinge nur zur Hölle privat zu markieren. Es wird dir nicht wirklich etwas bringen und jemand, der den Code liest, könnte der Entscheidung eine gewisse Bedeutung beilegen, wenn es wirklich keine gibt.

Ich würde die Notwendigkeit all dieser Komplexität in Frage stellen. Sehen Sie sich an: String.compareToIgnoreCase()

Sie möchten, dass diese Felder private sind, also markieren Sie sie private . Wenn ein Mitglied weder public nicht private markiert ist, wird etwas verdächtig. Markieren Sie auch Felder, die final nicht ändern sollen. Dinge standardisiert zu halten, bedeutet weniger Nachdenken oder zumindest weniger Nachdenken über das Irrelevante und weniger beim Modifizieren von Code.

Aus der Sicht der Sprache besteht der einzige wirkliche Unterschied darin, dass Sie jetzt, wenn Sie eine Basisklasse im selben Paket erweitert haben, Felder ausgeblendet oder "package-private" (Standardzugriff) -Methoden überschrieben haben. Die Mitglieder können auch durch Reflektion (ohne setAccessible ) durch Code im selben Paket erreicht werden (dies kann Auswirkungen auf die Sicherheit des mobilen Codes haben).

Unterschied zwischen Standard und geschützt.

geschützt : Objekt / Methode ist für alle Klassen zugänglich, die sich im selben Paket befinden, und auch für Sub- / Erweiterungsklassen zugänglich.

Standard : Objekt / Methode ist für alle Klassen zugänglich, die sich im selben Paket befinden.

Was ist Ihre Absicht von Ihrem Objekt / Methode und Code-Modifikator entsprechend? Erlaube dir nicht, verwirrt zu sein, wenn du nach sechs Monaten zum Code zurückkehrst, weil du in riesigen Projekten wissen willst, dass auf das Objekt / die Methode anderswo zugegriffen wird oder nicht.

In drei Wochen, nicht nur Monaten, würden Sie vergessen, was die beabsichtigte Zugänglichkeit dieser Objekte, 101% garantiert. Wenn Sie also ein riesiges Projekt hätten und hundert Modifikatoren hätten, die nicht spezifisch seien und Sie den Code unbedingt aktualisieren wollten, wären Sie frustriert, wenn Sie diese 100 Objekte / Methoden referenzieren müssten. Vielleicht hat jemand Ihr Glas genommen und die versteckten Kekse in ihnen gefunden und sie benutzt, dann haben Sie Ihren Code geändert und den Code von jemandem gebrochen.

Codieren Sie Ihre Modifikatoren entsprechend Ihrer Absicht, es sei denn, Sie haben eines oder mehrere davon:

1. Sie haben keine Lust mehr zu arbeiten in großen Java-Projekten.

2. du bist ein     extrem intelligent hoch     funktionierende autistische Person, die hat     eine indizierte Erinnerung an jedes Ereignis von     Ihr Leben und kann einen vollständig funktionsfähigen Peer-Peer-Filesharing-Dienst schreiben     innerhalb von zwei Wochen auf einem Laptop in einem     Café.

3. Sie benutzen es bewusst     als ein weiteres Werkzeug, um Ihre zu verschleiern     Code.