Sind Mitglieder / Felder wirklich so schlecht geschützt?

StackOverflow https://stackoverflow.com/questions/3182653

Frage

Nun, wenn Sie die Namenskonventionen in der MSDN für C # lesen, werden Sie feststellen, dass es heißt, dass Eigenschaften sind immer über öffentliche bevorzugt und geschützten Bereichen. Ich habe sogar von einigen Leuten wurde gesagt, dass man nie öffentliche oder geschützte Felder verwenden sollte. Jetzt werde ich zustimme ich habe noch einen Grund zu finden, in dem ich einen öffentlichen Bereich haben muß, bin aber geschützte Felder wirklich so schlimm?

Ich kann es sehen, wenn Sie brauchen, um sicherzustellen, dass bestimmte Plausibilitätsprüfungen durchgeführt werden, wenn Ermitteln / Setzen Sie den Wert jedoch viel von der Zeit, die wie zusätzlichen scheint nur Overhead meiner Meinung nach. Ich meine lässt sagen, dass ich eine Klasse GameItem mit Feldern für basename, prefixName haben und suffixName. Warum sollte ich den Aufwand sowohl die Eigenschaften zu schaffen (C#) oder Accessormethoden und die Leistung schlug ich auftreten würde (wenn ich dies tun, für jedes einzelne Feld in einer Anwendung, ich bin sicher, dass es würde fügt ein wenig weniger auf besonders in bestimmten Sprachen wie PHP oder bestimmte Anwendungen mit Leistung entscheidend ist wie Spiele)?

War es hilfreich?

Lösung

Sind geschützte Mitglieder / Felder wirklich so schlimm?

Nein. Sie sind viel, viel schlimmer.

Sobald ein Mitglied als private mehr zugänglich ist, Sie machen Garantien zu anderen Klassen, wie das Mitglied verhalten wird. Da ein Feld völlig unkontrolliert ist, es setzt „in der Wildnis“ öffnet Ihre Klasse und Klassen, die vererben oder interact mit Ihrer Klasse zu höheren Bug Risiko. Es gibt keine Möglichkeit zu wissen, wenn ein Feldänderungen, keine Art und Weise zu steuern, wer oder was sie sich ändert.

Wenn jetzt oder irgendwann in der Zukunft, alle Ihre Code jemals auf einem Feld hängt einige bestimmten Wert, Sie müssen jetzt Gültigkeitsprüfungen und Ausweich Logik hinzufügen, falls es nicht der erwartete Wert - jeden Ort, den Sie es verwenden, . Das ist eine riesige Menge an vergebliche Mühe, wenn Sie nur es stattdessen eine verdammt Eigenschaft gemacht haben könnte;)

Der am besten Weg zum Austausch von Informationen mit Ableitung Klassen ist die Nur-Lese-Eigenschaft : 

protected object MyProperty { get; }

Wenn Sie unbedingt Haben machen, lesen / schreiben, nicht. Wenn Sie wirklich, wirklich machen müssen, um es read-write, überdenken Sie Ihr Design. Wenn Sie es noch brauchen read-write zu sein, entschuldige mich bei Ihren Kollegen und tun es nicht wieder:)

Viele Entwickler glauben - und werden Ihnen sagen -, dass diese allzu streng. Und es ist wahr, dass man erhalten, indem sehr gut ohne diese strengen Vorgaben zu machen. Aber diesen Ansatz werden Sie von bemerkenswert robuster Software von nur immer gehen helfen. Sie werden viel weniger Zeit Fehler zu beheben verbringen.

Und in Bezug auf alle Bedenken über die Leistung - nicht. Ich garantiere, Sie werden nie, in Ihrer gesamten Karriere, Code zu schreiben, so schnell, dass der Engpass ist der Call-Stack selbst.

Andere Tipps

OK, downvote Zeit.

  • Zu allererst werden Eigenschaften nie verletzt Leistung (vorausgesetzt, dass sie nicht viel tun). Das ist, was jeder andere sagt, und ich stimme zu.

  • Ein weiterer Punkt ist, dass die Eigenschaften gut sind, dass Sie Haltepunkte in ihnen zu capture Ermitteln / Setzen von Veranstaltungen platzieren können und herausfinden, woher sie kommen.

Der Rest der Argumente stört mich auf diese Weise:

  • Sie klingen wie "Argument von Prestige". Wenn MSDN sagt es, oder einige bekannte Entwickler oder Autor, den jeder sagt, es mag, es muss sein so.

  • Sie sind auf der Idee, dass Datenstrukturen viele inkonsistente Zustände haben, und müssen geschützt werden gegen wandern oder in diesen Staaten gelegt. Da (wie mir scheint) Datenstrukturen Art und Weise überbetont in der aktuellen Lehre, dann in der Regel sie Sie diese Schutzmechanismen müssen. Weit mehr vorzuziehen ist, zu Datenstruktur minimiert , so dass es normalisiert zu werden neigt und nicht im Widerspruch Staaten zu haben. Wenn dann ein Mitglied einer Klasse geändert wird, wird es einfach geändert, anstatt beschädigt. Immerhin irgendwie viele gute Software war / ist in C geschrieben, und die leiden nicht massiv aus Mangel an Schutz.

  • Sie basieren auf Defensive auf die Spitze getrieben Codierung. Es basiert auf der Idee, dass Ihre Klassen werden in einer Welt verwendet werden, wenn der Code der sonst niemand trauen kann nicht deine Sachen Gans. Ich bin sicher, es gibt Situationen, in denen dies der Fall ist, aber Ich habe sie noch nie gesehen. Was I Haben ist Situationen gesehen, in denen die Dinge schrecklich kompliziert gemacht um Schutz zu bekommen, für die es keine Notwendigkeit war, und zu versuchen, die Konsistenz von Datenstrukturen zu schützen, die schrecklich zu kompliziert waren und un-normalisierten .

In Bezug auf Felder vs. Eigenschaften kann ich aus zwei Gründen denkt für Bevorzugung des Eigenschaft in der öffentlichen Schnittstelle (geschützt ist auch öffentlich in dem Sinne, dass jemand anderes als nur Ihre Klasse sehen kann).

  • Eigenschaften Machen gibt Ihnen eine Möglichkeit, die Umsetzung zu verstecken. Es erlaubt Sie auch, die Implementierung zu ändern, ohne den Code zu ändern, dass Verwendungen es (zum Beispiel, wenn Sie die Art und Weise entscheiden, um Daten in der Klasse gespeichert werden)

  • Viele Werkzeuge, dass die Arbeit mit Klassen mit Reflexion nur auf Eigenschaften konzentrieren (zum Beispiel, ich glaube, dass einige Bibliotheken für die Serialisierung Arbeit auf diese Weise). Mit konsequent Eigenschaften macht es einfacher, diese Standard-.NET-Tools zu verwenden.

In Bezug auf Gemeinkosten:

  • Wenn der Getter / Setter ist die übliche Linie Stück Code, der einfach liest / den Wert eines Feldes setzt, dann sollte der JIT der Lage sein, den Anruf inline, also gibt es keine Leistung overhad.

  • Kopf syntaktische stark reduziert, wenn Sie automatisch implementiert Eigenschaften mit (C # 3.0 und höher), so dass ich glaube nicht, dass dies ein Problem ist: 

    protected int SomeProperty { get; set; }

    In der Tat, dies ermöglicht es Ihnen zum Beispiel set machen geschützt und get Öffentlichkeit sehr leicht, so dass diese noch eleganter als die Verwendung von Feldern sein kann.

öffentliche und / oder geschützte Felder sind schlecht, weil sie von außerhalb der deklarierte Klasse ohne Validierung manipuliert werden können; so können sie die Einkapselung Prinzip der objektorientierten Programmierung werden die brechen.

Wenn Sie Verkapselung verlieren, verlieren Sie den Vertrag der deklarierte Klasse; garantieren Sie nicht, dass die Klasse verhält sich wie beabsichtigt oder zu erwarten.

Mit einer Eigenschaft oder eine Methode, um Zugriff auf das Feld, das Sie Verkapselung zu halten ermöglicht, und erfüllen den Auftrag der deklarierte Klasse.

Ich bin mit der Nur-Lese-Eigenschaft Antwort. Aber hier zu spielen Advocatus Diaboli, es hängt wirklich davon ab, was du tust. Ich werde glücklich sein, ich mit öffentlichen Mitgliedern der ganzen Zeit schreibe Code zugeben (i auch nicht Kommentar tun, folgen Richtlinien, oder einer der Formalitäten).

Aber wenn ich bei der Arbeit bin, das ist eine andere Geschichte.

Es hängt tatsächlich auf, wenn Ihre Klasse ist eine Datenklasse oder ein Verhalten Klasse.

Wenn Sie halten Ihr Verhalten und Daten getrennt , ist es in Ordnung, die Daten Ihrer Daten zu belichten Klassen, solange sie kein Verhalten haben.

Wenn die Klasse eine Verhaltensklasse ist, dann sollte es keine Daten aus.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top