Ich habe bemerkt, dass die Smalltalk-Sprache kein Konzept von privaten / geschützten Methoden hat. Alle Methoden sind öffentlich. Ausgehend von einem Java / C ++ - Hintergrund habe ich dies als eine grundlegende Schwäche der Sprache betrachtet, da jede in Smalltalk erstellte Anwendung vollständig manipulierbar wäre. Ich denke, man könnte sich darauf verlassen, Konventionen zu benennen, um die öffentliche API zu dokumentieren, und Präfix-Methoden, um sie als privat zu kennzeichnen (ich glaube, Squeak macht das), aber es ist immer noch komplett offen.
Hat dieser Ansatz Vorteile gegenüber expliziten Zugriffsmodifikatoren zur Steuerung? Zugriff auf Methodenaufrufe?
Tatsächlich ist der Smalltalk-Weg, private Methoden in die Kategorie "privat" zu stellen. Dies zeigt an, dass Sie diese Methoden nicht verwenden sollten, aber dies wird natürlich nicht erzwungen.
Das ist Absicht - es ist eine Funktion, kein Bug. Smalltalk wurde von Anfang an als offenes System konzipiert.
Einige Vorteile:
Private und geschützte Methoden sind in der Tat eine signifikante Schwäche von Sprachen wie C ++, Java und C #. Sie sagen grundsätzlich zu ihren Nutzern: Ich möchte nicht lernen und mich weiterentwickeln. Die Konsequenz daraus (und viel früher Bindung) ist, dass diese Sprachen viel mehr BDUF benötigen und somit für einen modernen (agilen) Entwicklungsprozess weit weniger brauchbar sind.
Die erste Frage ist, um welche privaten / geschützten Zugriffsmodifizierer es sich handelt? Grundsätzlich geht es nicht um Sicherheit. Es geht darum, dem Benutzer die richtige Schnittstelle zur Verfügung zu stellen. Davon ausgehend macht es wenig Unterschied, ob Kategorien geschützt / privat und ein Sprachkonstrukt dafür sind.
Ich würde sogar sagen, dass das Vorhandensein eines privaten / geschützten Sichtbarkeitsmodifikators dem Problem mehr Komplexität bringt, als es tatsächlich löst.
Außerdem glaube ich nicht, dass private / geschützte Sichtbarkeit eine gute Antwort auf dieses Problem
Tags und Links smalltalk coding-style gnu-smalltalk public-method