Lass mich dir eine Analogie geben.
Ich komme aus einem Teil der Welt, wo Englisch nicht die Hauptsprache ist. Aber es ist notwendig für alle Dinge im Leben
Während eines dieser üblichen Tage in meiner Jugendzeit sagte ich etwas sehr lustiges auf Englisch. Dann sagte mein Vater: "Sohn, denke auf Englisch. Dann wirst du fließend sprechen "
Ich denke, dass es perfekt auf diese Situation zutrifft.
Denken Sie nach, und stellen Sie Best Practices auf Ihrem Spielplatz in Frage. Sie werden bald erkennen, was für was am besten ist. Warum werden Eigenschaften überhaupt benötigt? Warum sollte das öffentlich sein? Warum sollte ich kein virtuelles Mitglied vom Konstruktor aufrufen? Lassen Sie mich versuchen, den "neuen" Modifikator für einen Methodenaufruf zu verwenden. Was passiert, wenn ich 10 verschachtelte Ebenen von if-then-else schreibe? und versuche es nach 10 Tagen erneut zu lesen . Warum zum Teufel sollte ich ein Fabrikmuster für ein einfaches Projekt verwenden. Und so weiter.
Und dann werden Sie erkennen, ohne auf Ihren Fuß zu schießen , warum Designmuster Muster sind ...
Die Verletzung allgemeiner Prinzipien ist immer "ok"! Es ist kein Fehler, ein Prinzip zu verletzen, aber es ist ein Kompromiss. Die Kosten für das Schreiben von sauberem Code sind umso höher, je länger Ihre Software überleben wird. Meine Meinung ist: Im Zweifelsfall mach es sauber!
Natürlich ist es in Ordnung. Es ist dein Code , du kannst damit machen, was du willst. Persönlich versuche ich mich auch in meinem privaten Code an gute Praktiken zu halten, nur um es zu einer natürlichen Gewohnheit zu machen, so dass ich nicht darüber nachdenken muss.
Die kurze Antwort ist ja, wenn du glaubst, dass du viel gewinnst, indem du Dinge öffentlich machst, anstatt private mit Accessoren, dann kannst du das gerne tun. Konsistenz, denke ich, ist die größte Sache, die man im Kopf behalten sollte. Machen Sie zum Beispiel einige Variablen nicht öffentlich, andere nicht. Machen Sie das gleiche auf der ganzen Linie, wenn Sie mit Best Practices brechen. Es kommt zu einem Kompromiss. Kaum jemand folgt vielen IEEE-Spezifikationen, wie Software-Engineering ausgeführt und dokumentiert werden sollte, da der Overhead viel zu groß ist und nicht bewältigt werden kann. Gleiches gilt für die persönliche, leichte Programmierung. Es ist okay, etwas schnell und schmutzig zu machen, gewöhn dich einfach nicht daran.
Öffentliche Mitglieder sind im Entwurfsmuster für Datenübertragungsobjekte zulässig:
In der Regel sind die Member im Transfer-Objekt als public definiert, wodurch die Methoden get und set nicht mehr benötigt werden.
Einer der Hauptvorteile von OOP ist die Skalierung und Wartbarkeit. Durch die Kapselung von Code kann die Implementierung verborgen werden. Dies bedeutet, dass andere Programmierer die Implementierung nicht kennen müssen und den internen Status des Objekts nicht ändern können. Wenn Ihre Sprache keine Eigenschaften unterstützt, erhalten Sie eine Menge Code, der Ihr Projekt verschleiert und aufbläht. Wenn der Code nicht von mehreren Programmierern bearbeitet werden muss, produzieren Sie keine wiederverwendbare Komponente, und Sie sind der Wartungsprogrammierer, dann können Sie auf jede Art programmieren, die es Ihnen ermöglicht, Dinge zu erledigen .
Muss eine Zofe am Morgen ihr eigenes Bett machen, um richtig zu üben?Randnotiz: Es hängt auch von der Sprache ab:
In Scala , nach dem Uniform Access Prinzip , lesen und schreiben die Kunden Feldwerte so, als ob sie öffentlich zugänglich wären, auch wenn dies in einigen Fällen der Fall ist Methoden aufrufen. Der Betreuer der Klasse hat die Freiheit, die Implementierung zu ändern, ohne dass die Benutzer Codeänderungen vornehmen müssen.
Scala behält Feld- und Methodennamen in demselben Namespace bei.
Viele Sprachen wie Java enthalten Feld- und Methodennamen in separaten Namespaces.
Diese Sprachen können jedoch das Prinzip des einheitlichen Zugriffs nicht unterstützen, es sei denn, sie bauen Ad-hoc-Unterstützung in ihren Grammatiken oder Compilern ein.
Die wirkliche Frage ist also:
Welchen Service setzen Sie frei (hier mit einem öffentlichen Feld) ?.
Wenn der Service (get / set einen bestimmten Typ Wert) für Ihre API sinnvoll ist, dann ist die "Verknüpfung" legitim.
Solange Sie dieses Feld schließlich einkapseln, ist es in Ordnung, weil Sie die Verknüpfung für den "richtigen" Grund (API und Service-Exposition), gegen den "falschen" Grund (schneller Ad-hoc-Zugriff) gemacht haben.
Ein guter Komponententest (ähnlich wie der Benutzer Ihrer API) kann Ihnen helfen, zu überprüfen, ob auf dieses Feld direkt zugegriffen werden soll oder ob es nur für die interne Entwicklung anderer Klassen innerhalb Ihres Programms nützlich ist.
Hier ist meine Meinung:
Ich würde empfehlen, öffentliche Bereiche zu meiden. Sie haben eine unangenehme Angewohnheit, dich später zu beißen, weil du sie nicht kontrollieren kannst. (Das Wort, nach dem Sie hier suchen, ist Volatilität. ) Wenn Sie sich entscheiden, ihre interne Implementierung zu ändern, müssen Sie viel mehr Code berühren.
Dafür wiederum sind Refactoring-Tools gedacht. Wenn Sie ein anständiges Refactoring-Tool haben, ist das bei weitem nicht so schwierig.
Es gibt keine Wunderwaffe. Ich kann das nicht genug wiederholen. Wenn Sie viel zu tun haben und es schnell erledigen müssen, ist das Schreiben einer Codezeile statt acht (wie in Visual Basic) sicherlich schneller.
Regeln sollten gebrochen werden. Wenn eine Regel in Ihrem Fall nicht unbedingt zutrifft, verwenden Sie sie nicht. Entwurfsmuster, Kodierungsrichtlinien, Gesetze und Best Practices sollten nicht als Zwangsjacke behandelt werden, die dazu führt, dass Sie Ihren Code unnötigerweise so kompliziert machen müssen, dass er enorm komplex und schwer zu verstehen und zu warten ist. Lassen Sie sich nicht von jemandem in die Praxis zwingen, nur weil es populär oder "Standard" ist, wenn es Ihren Anforderungen nicht entspricht.
Auch dies ist eine subjektive Meinung und Ihre Laufleistung kann variieren.
Tags und Links field