it-swarm-eu.dev

Warum brauchen wir private Variablen?

Warum brauchen wir private Variablen in Klassen?

Jedes Buch über Programmierung, das ich gelesen habe, sagt, dass dies eine private Variable ist. So definieren Sie sie, hören aber dort auf.

Der Wortlaut dieser Erklärungen kam mir immer so vor, als hätten wir wirklich eine Vertrauenskrise in unseren Beruf. Die Erklärungen klangen immer so, als wollten andere Programmierer unseren Code durcheinander bringen. Es gibt jedoch viele Programmiersprachen, die keine privaten Variablen haben.

  1. Was verhindern private Variablen?

  2. Wie entscheiden Sie, ob eine bestimmte Immobilie privat sein soll oder nicht? Wenn standardmäßig jedes Feld privat sein SOLLTE, warum gibt es dann öffentliche Datenelemente in einer Klasse?

  3. Unter welchen Umständen sollte eine Variable veröffentlicht werden?

216
mwallace

Es geht nicht so sehr um Vertrauen, sondern darum, die Komplexität zu managen.

Auf ein öffentliches Mitglied kann von außerhalb der Klasse zugegriffen werden, was aus praktischen Gründen "möglicherweise überall" bedeutet. Wenn mit einem öffentlichen Feld etwas schief geht, kann der Schuldige überall sein. Um den Fehler aufzuspüren, müssen Sie sich möglicherweise eine Menge Code ansehen.

Im Gegensatz dazu kann auf ein privates Mitglied nur innerhalb derselben Klasse zugegriffen werden. Wenn also etwas schief geht, muss normalerweise nur eine Quelldatei angezeigt werden. Wenn Ihr Projekt eine Million Codezeilen enthält, Ihre Klassen jedoch klein gehalten werden, kann dies den Aufwand für die Fehlerverfolgung um den Faktor 1000 reduzieren.

Ein weiterer Vorteil hängt mit dem Konzept der "Kopplung" zusammen. Ein öffentliches Mitglied m einer Klasse A, die von einer anderen Klasse B verwendet wird, führt eine Abhängigkeit ein: Wenn Sie m in A ändern müssen Sie auch die Verwendung von m in B überprüfen. Schlimmer noch, nichts in der Klasse A sagt Ihnen, wo m verwendet wird, also müssen Sie erneut die gesamte Codebasis durchsuchen. Wenn es sich um eine Bibliothek handelt, die Sie schreiben, müssen Sie sogar sicherstellen, dass Code außerhalb Ihres Projekts aufgrund Ihrer Änderung nicht beschädigt wird. In der Praxis bleiben Bibliotheken in der Regel so lange wie möglich bei ihren ursprünglichen Methodensignaturen, egal wie schmerzhaft sie sind, und führen dann mit einem größeren Versionsupdate einen Block mit Änderungen ein. Im Gegensatz dazu können Sie bei privaten Mitgliedern Abhängigkeiten sofort ausschließen - auf sie kann nicht von außen zugegriffen werden, sodass alle Abhängigkeiten in der Klasse enthalten sind.

In diesem Zusammenhang umfassen "andere Programmierer" Ihr zukünftiges und vergangenes Selbst. Wahrscheinlich wissen Sie jetzt , dass Sie dieses Ding X nicht mit Ihrer Variablen Y machen sollten, aber Sie müssen drei Monate später vergessen haben Wenn ein Kunde Sie dringend benötigt, um eine Funktion zu implementieren, und Sie sich fragen, warum X Y auf dunkle Weise bricht.

Also, wann Sie Dinge privat machen sollten: Ich würde sagen, machen Sie standardmäßig alles privat und legen Sie dann nur die Teile offen, die unbedingt öffentlich sein müssen. Je mehr Sie privat machen können, desto besser.

312
tdammers

Private Variablen verhindern, dass Personen von bestimmten Teilen Ihres Codes abhängig sind. Angenommen, Sie möchten eine Datenstruktur implementieren. Sie möchten, dass Benutzer Ihrer Datenstruktur sich nicht darum kümmern , wie Sie sie implementiert haben, sondern die Implementierung nur über Ihre gut definierte Schnittstelle verwenden. Der Grund dafür ist, dass Sie, wenn niemand von Ihrer Implementierung abhängig ist, diese jederzeit ändern können. Sie können beispielsweise die Back-End-Implementierung ändern, um die Leistung zu verbessern. Alle anderen Entwickler, die von Ihren Implementierungen abhängig waren, werden kaputt gehen, während die Benutzer der Benutzeroberfläche in Ordnung sind. Die Flexibilität, Implementierungen zu ändern, ohne die Klassenbenutzer zu beeinträchtigen, ist ein großer Vorteil, den die Verwendung privater Variablen (und allgemeiner Kapselung ) bietet.

Es ist auch nicht wirklich eine "Vertrauenskrise". Wenn Sie Daten veröffentlichen, können Sie nicht sicherstellen, dass niemand davon abhängig ist. Es ist oft sehr praktisch, sich auf eine implementierungsspezifische Variable zu verlassen, anstatt die öffentliche Schnittstelle zu durchlaufen, insbesondere in der Hitze einer Frist. Außerdem werden Entwickler nicht immer erkennen, dass sie von etwas abhängig sind, das sich ändern könnte.

Ich hoffe, diese Art beantwortet Ihre anderen Fragen. Alle Ihre Implementierungsdetails sollten privat sein, und der öffentliche Teil sollte eine kleine, präzise und genau definierte Schnittstelle für die Verwendung Ihrer Klasse sein.

111
Oleksi

Das Schlüsselwort hier ist Kapselung . In OOP) möchten Sie private Variablen verwenden, um die ordnungsgemäße Kapselung Ihrer Objekte/Klassen zu erzwingen.

Während andere Programmierer nicht darauf aus sind, Sie zu erreichen, interagieren sie mit Ihrem Code. Wenn Sie eine Variable nicht privat machen, verweisen sie möglicherweise in ihrem eigenen Code darauf, ohne Schaden anrichten zu wollen. Wenn Sie jedoch zu Ihrer Klasse zurückkehren und etwas ändern müssen, wissen Sie nicht mehr, wer welche Variable wo verwendet. Das Ziel der Kapselung besteht darin, die externe Schnittstelle der Klasse explizit zu machen, damit Sie wissen, dass nur diese (normalerweise) Methoden von anderen verwendet werden könnten.

  1. Private Variablen stellen daher sicher, dass die entsprechende Variable nur in der definierenden Klasse verbleibt. Wenn Sie es ändern müssen, ist die Änderung lokal für die Klasse selbst.

  2. In herkömmlichen Sprachen wie C++ oder Java machen Sie normalerweise alles privat und nur für entsprechende Getter und Setter zugänglich. Keine Notwendigkeit, wirklich viel zu entscheiden.

  3. Manchmal z. In einer C++ - Struktur benötigen Sie eine Klasse nur, um mehrere Dinge zu gruppieren. Stellen Sie sich beispielsweise eine Vektorklasse vor, die nur ein x und ein y Attribut hat. In diesen Fällen können Sie den direkten Zugriff auf diese Attribute zulassen, indem Sie sie als öffentlich deklarieren. Insbesondere muss es Ihnen egal sein, ob ein Code außerhalb ein Objekt Ihrer Klasse ändert, indem neue Werte direkt in x oder y geschrieben werden.

Beachten Sie außerdem, dass diese Angelegenheit in anderen Sprachen als etwas anders angesehen wird. Beispielsweise betonen Sprachen, die stark in der funktionalen Programmierung verwurzelt sind, die Unveränderlichkeit von Daten, d. H. Datenwerte können überhaupt nicht geändert werden. In solchen Fällen müssen Sie sich nicht darum kümmern, was andere Programmierer (oder vielmehr deren Code) mit Ihren Daten tun. Sie können einfach nichts tun, was sich auf Ihren Code auswirken könnte, da alle Daten unveränderlich sind.

In diesen Sprachen erhalten Sie daher etwas namens einheitliches Zugriffsprinzip , bei dem Methoden wie Getter und Setter bewusst nicht unterschieden werden, sondern ein direkter Zugriff auf die Variable/Funktion bereitgestellt wird. Man kann also sagen, dass private Deklarationen in objektorientierten Szenarien viel beliebter sind.

Dies zeigt auch, wie Sie durch die Erweiterung Ihres Wissens auf andere Bereiche vorhandene Konzepte auf völlig neue Weise betrachten können.

26
Frank

Private Variablen stellen sicher, dass spätere Verweise außerhalb des Bereichs eines Objekts oder einer Funktion andere Variablen nicht versehentlich beeinflussen. Bei großen Programmierprojekten kann dies dazu beitragen, viele interessante Probleme zu vermeiden (die normalerweise nicht vom Compiler erfasst werden).

Mit prototypischen Sprachen wie Javascript können Benutzer beispielsweise Variablen nach Belieben verputzen:

function SomeObject() {
    this.a = 2; //Public (well, actually protected) variable

    this.showA = function() {
        alert(this.a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 3. Uh oh!

Wenn diese Variable privat wäre, könnte sie von außen nicht geändert werden:

function SomeObject() {
    var a = 2; //Private variable

    this.showA = function() {
        alert(a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 2

Allerdings müssen nicht alle Variablen privat sein, und eine übermäßige Verwendung privater Variablen kann den Code tatsächlich umständlicher machen. Triviale Felder, die ein Objekt nicht ernsthaft beeinflussen, benötigen keine Methoden get() und set().

Private Variablen erleichtern es auch, Code in Zukunft zu erweitern, ohne sich auf umfangreiche Dokumentationen zu verlassen, was die vielen öffentlichen Variablen bewirken. Es besteht weniger die Gefahr, dass die Funktionalität versehentlich unterbrochen wird, wenn weniger Variablen überschrieben werden können.

Öffentliche Variablen sollten verwendet werden, wenn ein Objekt/eine Funktion auf andere Objekte/Funktionen zugreift, da private Variablen dies in der Regel nicht können. Möglicherweise haben Sie einige bis einige öffentliche Variablen, und es ist keine schlechte Sache, sie zu verwenden, wenn sie richtig verwendet werden.

7
Jeffrey Sweeney

Es gibt einige gute Antworten, in denen die Vorteile für zukünftige Betreuer und Benutzer einer Klasse angeführt werden. Das ursprüngliche Design bietet jedoch auch Vorteile. Es bietet eine klare Abgrenzung zwischen dem Zeitpunkt, zu dem Sie sich die Dinge erleichtern möchten, und dem Ziel, dem Klassenbenutzer die Dinge zu erleichtern. Wenn Sie zwischen öffentlich und privat wählen, signalisiert dies Ihrem Gehirn, in den einen oder anderen Modus zu wechseln, und Sie erhalten eine bessere API.

Es ist nicht so, dass Sprachen ohne Privatsphäre ein solches Design unmöglich machen, nur weniger wahrscheinlich. Anstatt aufgefordert zu werden, etwas wie foo.getBar() zu schreiben, neigen die Leute dazu zu denken, dass ein Getter nicht notwendig ist, weil es einfacher ist, foo.bar Zu schreiben, aber dann wird diese Entscheidung nicht erneut getroffen, wenn Sie später mit längeren Monstrositäten wie obj.container[baz].foo.bar enden. Programmierer, die noch nie in einer strengeren Sprache gearbeitet haben, sehen möglicherweise nicht einmal, was daran falsch ist.

Aus diesem Grund verwenden Menschen in Sprachen ohne Datenschutz häufig Namensstandards, die dies simulieren, z. B. indem allen "privaten" Mitgliedern ein Unterstrich vorangestellt wird. Es ist ein nützliches Signal, auch wenn die Sprache es nicht erzwingt.

7
Karl Bielefeldt

Alle Variablen sollten privat sein, es sei denn, sie müssen unbedingt öffentlich sein (was fast nie der Fall ist, Sie sollten Eigenschaften/Getter und Setter verwenden).

Variablen geben weitgehend den Status des Objekts an, und private Variablen verhindern, dass andere Benutzer den Status des Objekts ändern.

3
bbb

Siehe dieser Beitrag von mir zu einer verwandten Frage zu SO .

Kurz gesagt, mit dem variablen Bereich können Sie den Verbrauchern Ihres Codes zeigen, womit sie sich anlegen sollten und was nicht. Eine private Variable kann Daten enthalten, die mithilfe eines Eigenschaftssetzers oder einer Verarbeitungsmethode "überprüft" wurden, um sicherzustellen, dass sich das gesamte Objekt in einem konsistenten Zustand befindet. Das direkte Ändern des Werts der privaten Variablen kann dazu führen, dass das Objekt inkonsistent wird. Wenn jemand es privat macht, muss er wirklich hart arbeiten und über sehr hohe Laufzeitberechtigungen verfügen, um es zu ändern.

Das richtige Scoping der Mitglieder ist daher der Schlüssel zum selbstdokumentierenden Code.

2
KeithS

Es hat nichts mit Vertrauen oder Angst vor Angriffen zu tun, es geht ausschließlich um die Kapselung - nicht darum, dem Benutzer der Klasse unnötige Informationen aufzuzwingen.

Betrachten Sie private Konstanten - sie sollten keine geheimen Werte enthalten (diese sollten an anderer Stelle gespeichert werden), sie können nicht geändert werden, sie müssen nicht an Ihre Klasse übergeben werden (andernfalls müssten sie öffentlich sein). Sie können nur als Konstanten in ANDEREN Klassen verwendet werden. Aber wenn Sie das tun, hängen diese Klassen jetzt von Ihrer Klasse ab, um Arbeiten zu erledigen, die nichts mit Ihrer Klasse zu tun haben. Wenn Sie die Konstante ändern, werden möglicherweise andere Klassen unterbrochen. Das ist von beiden Seiten schlecht - als Autor Ihrer Klasse möchten Sie, dass sich die Freiheit so weit wie möglich ändert, und Sie möchten sich nicht um Dinge kümmern, die außerhalb Ihrer Kontrolle liegen. Ein Verbraucher Ihrer Klasse möchte sich auf die offengelegten Details Ihrer Klasse verlassen können, ohne sich Sorgen machen zu müssen, dass Sie sie ändern und ihren Code brechen.

Ein Verbraucher Ihrer Klasse möchte alles wissen, was für die Interaktion mit Ihrer Klasse erforderlich ist, und möchte nichts über Ihre Klasse wissen, das nichts daran ändert, wie sie dies tun: Es ist eine nutzlose Kleinigkeit. Wenn Sie eine Sprache mit Reflexion verwendet haben, wie oft haben Sie sie verwendet, um nicht zu lernen, wie eine Klasse etwas tut oder wo sie unerwartet eine Ausnahme auslöst, sondern einfach den Namen der privaten Felder und Methoden? Ich wette nie. Weil Sie dieses Wissen nicht gebrauchen können.

2
jmoreno
  • Was verhindern private Variablen?

Es geht darum, klar zu machen, welche Eigenschaften und Methoden Schnittstelle sind und welche tatsächlich Kernfunktionen sind. Bei öffentlichen Methoden/Eigenschaften handelt es sich um anderen Code, häufig um Code anderer Entwickler, der Ihre Objekte verwendet. Ich habe noch nie in Teams mit mehr als 100 Mitarbeitern an demselben Projekt gearbeitet, aber nach meiner Erfahrung mit Teams von 3 bis 5 Personen mit bis zu 20 anderen Entwicklern, die von mir geschriebenes Material verwenden, scheinen die anderen Bedenken albern.

Hinweis: Ich bin hauptsächlich ein JavaScript-Entwickler. Ich mache mir im Allgemeinen keine Sorgen darüber, dass andere Entwickler meinen Code anzeigen, und ich bin mir bewusst, dass sie meine Inhalte jederzeit einfach neu definieren können. Ich gehe davon aus, dass sie kompetent genug sind, um zu wissen, was sie zuerst tun. Wenn nicht, ist es unwahrscheinlich, dass ich in einem Team arbeite, das keine Quellcodeverwaltung verwendet.

  • Wie entscheiden Sie, ob ein bestimmter Satz von Eigenschaften privat sein soll oder nicht? Wenn standardmäßig jedes Feld privat sein SOLLTE, warum gibt es dann öffentliche Datenelemente in einer Klasse?

Früher dachte ich, es sei albern, Getter und Setter auf private Grundstücke zu setzen, wenn Sie nicht wirklich irgendeine Art von Validierung oder andere spezielle Behandlung des einzustellenden Grundstücks durchgeführt haben. Ich denke immer noch nicht, dass es immer notwendig ist, aber wenn Sie mit großem Umfang und hoher Komplexität zu tun haben, aber vor allem mit vielen anderen Entwicklern, die sich darauf verlassen, dass sich Ihre Objekte konsistent verhalten, kann es nützlich sein, Dinge in einem zu tun konsequenter und einheitlicher Weg. Wenn Leute Methoden sehen, die getThat und setThat genannt werden, wissen sie genau, was die Absichten sind, und sie können ihre Objekte schreiben, um mit Ihren zu interagieren, mit der Erwartung, dass sie immer eher Tomaten als Tomahtos bekommen . Wenn sie dies nicht tun, wissen sie, dass Ihr Objekt ihnen etwas gibt, das es wahrscheinlich nicht sollte, was bedeutet, dass es einem anderen Objekt erlaubt, etwas mit diesen Daten zu tun, das es wahrscheinlich nicht sollte. Sie können dies bei Bedarf steuern.

Der andere große Vorteil ist, dass es einfacher ist, Ihre Objekte zu übergeben oder Werte anders zu interpretieren als ein Getter oder Setter, basierend auf einem unterschiedlichen Zustandskontext. Da sie mit einer Methode auf Ihre Inhalte zugreifen, ist es viel einfacher, die Funktionsweise Ihres Objekts später zu ändern, ohne anderen Code zu beschädigen, der davon abhängt. Das wichtige Prinzip ist, dass nur Ihr Objekt die Daten ändert, für die Sie es verantwortlich gemacht haben. Dies ist besonders wichtig, um Ihren Code locker zu koppeln. Dies ist ein großer Gewinn in Bezug auf Portabilität und einfache Modifikation.

  • Unter welchen Umständen sollte eine Variable veröffentlicht werden?

Bei erstklassigen Funktionen (Sie können Funktionen als Argumente übergeben) kann ich mir nicht viele gute Gründe vorstellen, außer dass dies bei kleineren Projekten nicht unbedingt erforderlich ist. Ohne sie haben Sie möglicherweise Mitglieder, die stark und regelmäßig von anderen Objekten in dem Maße verarbeitet werden, dass es ein bisschen mürrisch erscheint, ständig get aufzurufen und ein Objekt festzulegen, das diese Daten selbst nicht wirklich berührt, aber das in selbst würde mich fragen lassen, warum das Objekt für diese Daten verantwortlich war. Im Allgemeinen möchte ich meine Architektur auf Fehler überprüfen, bevor ich mich für eine öffentliche Dateneigenschaft entscheide. IMO, es ist nichts Falsches an einer Sprache, mit der Sie etwas tun können, was normalerweise eine schlechte Idee ist. Einige Sprachen stimmen nicht überein.

2
Erik Reppen

Ich werde anhand eines realen Beispiels über den Wert der Kapselung aus einer anderen Perspektive sprechen. Vor einiger Zeit (Anfang der 80er Jahre) wurde ein Spiel für den Radio Shack Color Computer namens Dungeons of Daggorath geschrieben. Vor einigen Jahren portierte Richard Hunerlach es von einer Papier-Assembler-Liste nach C/C++ ( http://mspencer.net/daggorath/dodpcp.html ). Einige Zeit später erhielt ich den Code und begann ihn neu zu faktorisieren, um eine bessere Kapselung zu erzielen ( http://dbp-consulting.com/stuff/ ).

Der Code wurde bereits in verschiedene Objekte zerlegt, um Zeitplanung, Video, Benutzereingaben, Dungeonerstellung, Monster usw. zu handhaben, aber man konnte definitiv erkennen, dass er vom Assembler portiert wurde. Meine größte Aufgabe war es, die Kapselung zu erhöhen. Damit meine ich, verschiedene Teile des Codes zu bekommen, um ihre Nasen aus dem Geschäft des anderen herauszuholen. Es gab zum Beispiel viele Stellen, an denen Videovariablen direkt geändert wurden, um eine gewisse Wirkung zu erzielen. Einige machten es mit Fehlerprüfung, andere nicht, andere hatten subtil unterschiedliche Vorstellungen davon, was es bedeutete, dieses Ding zu ändern. Es wurde viel Code dupliziert. Stattdessen musste der Videoabschnitt über eine Schnittstelle verfügen, um die gewünschten Aufgaben zu erfüllen, und der Code dafür konnte sich an einem Ort, einer Idee und einem Ort zum Debuggen befinden. So etwas war weit verbreitet. Jedes Objekt, auf das direkt auf jedes andere Objekt zugegriffen wurde, und jeder Code wurden überall dupliziert.

Als der Code auseinander gerissen wurde, verschwanden Fehler, die noch nicht einmal diagnostiziert worden waren. Der Code wurde qualitativ hochwertiger. Für jede Aufgabe wurde eine Stelle im Code verantwortlich, und es gab nur eine Stelle, an der sie richtig ausgeführt werden konnte. (Ich finde immer noch mehr, wenn ich den Code erneut durchlaufe.)

Alles, was an Ihrem Code sichtbar ist, ist Ihre Schnittstelle. Ob du es meinst oder nicht. Wenn Sie die Sichtbarkeit so weit wie möglich einschränken, werden Sie später nicht versucht sein, Code an der falschen Stelle abzulegen. Es macht deutlich, welcher Teil des Codes für welche Daten verantwortlich ist. Es sorgt für ein besseres, saubereres, einfacheres und eleganteres Design.

Wenn Sie ein Objekt für seine eigenen Daten verantwortlich machen und Schnittstellen für alle anderen bereitstellen, die etwas benötigen, wird Ihr Code um ein Vielfaches einfacher. Es fällt einfach raus. Sie haben kleine einfache Routinen, die nur eines tun. Weniger Komplexität == weniger Fehler.

2
phorgan1

Das Konzept OOP hat Vererbung hat eine seiner Funktionen (Java oder C++). Wenn wir also erben (dh wir werden auf die Variablen der geerbten Klasse zugreifen), besteht die Möglichkeit von Wir müssen also entscheiden, ob die Variablen geändert werden können oder nicht.

Nur zu diesem Zweck verwenden wir Zugriffsmodifikatoren in OOP. Einer der Modifikatoren ist privat, was bedeutet, dass nur diese Klasse darauf zugreifen kann. Jede andere Klasse kann diese Variablen nicht beeinflussen.

Wie wir wissen, bedeutet geschützt, dass die Klasse, die erben wird, auf sie zugreifen kann.

Warum es in OOP ein Modifikatorkonzept gibt, liegt an diesen Gründen (jede Klasse kann mit dem OOP -Konzept) auf andere Klassenvariablen zugreifen. Wenn es kein Modifikatorkonzept gibt, bedeutet dies, dass es schwierig gewesen wäre Klassen erben oder andere OOP Konzepte) verwenden.

1
rajNaveen

Wie von anderen angegeben, sind private Variablen gut, um Missbräuche zu vermeiden, die das Objekt in einen inkonsistenten Status führen, und schwer zu verfolgende Fehler und unvorhergesehene Ausnahmen.

Andererseits geht es bei den anderen meist um geschützte Felder.

Eine erweiterte Unterklasse hat vollen Zugriff auf geschützte Felder, wodurch das Objekt so fragil wird, als ob solche Felder öffentlich wären. Diese Fragilität ist jedoch auf die erweiterte Klasse selbst beschränkt (es sei denn, sie hat solche Felder noch stärker verfügbar gemacht).

Öffentliche Felder können daher nur schwer als gut angesehen werden. Bisher werden sie nur für Klassen verwendet, die als Konfigurationsparameter verwendet werden (eine sehr einfache Klasse mit vielen Feldern und ohne Logik, sodass diese Klasse nur als Parameter an übergeben wird eine Methode).

Auf der anderen Seite verringern private Felder die Flexibilität Ihres Codes für andere Benutzer.

Flexibilität gegen Probleme, Vor- und Nachteile :

Objekte, die durch Ihren Code in der Vanilla-Klasse mit geschützten Feldern instanziiert wurden, sind sicher und liegen in Ihrer alleinigen Verantwortung.

Auf der anderen Seite liegen Objekte, die Ihre Klasse mit geschützten Feldern erweitern und von den Benutzern Ihres Codes instanziiert werden, in ihrer Verantwortung, nicht in Ihrer.

Nicht gut dokumentierte geschützte Felder/Methoden oder wenn die Benutzer nicht wirklich verstehen, wie solche Felder und Methoden verwendet werden sollen, haben gute Chancen, sich selbst und Ihnen unnötige Probleme zu bereiten.

Auf der anderen Seite verringert das Privatisieren der meisten Dinge die Flexibilität der Benutzer und kann sie sogar davon abhalten, nach gewarteten Alternativen zu suchen, da sie möglicherweise keine Gabel erstellen und warten möchten, nur damit die Dinge auf ihre Weise geschehen.

Ein gutes Gleichgewicht zwischen privat, geschützt und öffentlich ist also wirklich wichtig.

Die Entscheidung zwischen privat und geschützt ist nun das eigentliche Problem.

Wann geschützt verwenden?

Jedes Mal, wenn Sie verstehen, dass ein Feld sehr flexibel sein kann, sollte es als geschützt codiert werden. Diese Flexibilität besteht darin, von Null zu werden (wobei Null immer überprüft und als gültiger Zustand erkannt wird, der keine Ausnahmen auslöst) bis hin zu Einschränkungen, bevor sie von Ihrer Klasse ex verwendet werden. > = 0, <100 usw. und automatisch für Über-/Unterlaufwerte festgelegt, wobei höchstens eine Warnmeldung ausgegeben wird.

Für ein solches geschütztes Feld könnten Sie also einen Getter erstellen und ihn nur verwenden (anstatt die Feldvariable direkt zu verwenden), während andere Benutzer ihn möglicherweise nicht verwenden, falls sie mehr Flexibilität für ihren spezifischen Code wünschen, wie in meinem Beispiel : Wenn negative Werte in ihrer erweiterten Klasse gut funktionieren sollen.

1
Aquarius Power

imo @tdammers ist nicht richtig und tatsächlich irreführend.

Private Variablen sind vorhanden, um Implementierungsdetails auszublenden. Ihre Klasse A verwendet möglicherweise ein array, um Partituren zu speichern. Morgen möchten Sie vielleicht stattdessen ein tree oder priority queue Verwenden. Alles, was die Benutzer Ihrer Klasse benötigen, ist eine Möglichkeit, Punktzahlen und Namen einzugeben addScore() und eine Möglichkeit, herauszufinden, wer die Top 10 getTop(n) sind.

Sie müssen nicht auf die zugrunde liegende Datenstruktur zugreifen. Klingt gut? Nun, es gibt einige Einschränkungen.

Sie sollten sowieso nicht viel Status speichern, das meiste davon wird nicht benötigt. Das Speichern des Status erschwert Ihren Code, selbst wenn er für eine bestimmte Klasse "getrennt" ist. Denken Sie darüber nach, diese private Variable hat sich wahrscheinlich geändert, weil ein anderes Objekt eine Methode dieser Klasse genannt hat. Sie müssen noch herausfinden, wann und wo diese Methode aufgerufen wurde und diese öffentliche Methode theoretisch überall aufgerufen werden kann.

Das Beste, was Sie tun können, ist, den Status Ihres Programms zu begrenzen und nach Möglichkeit reine Funktionen zu verwenden.

0
AturSams