Die gängigsten OO-Sprachen bieten ein Tool wie einen Modifikator für den Zugriff auf eine Methode oder ein Feld. Dies ist gut für erfahrene Programmierer, aber hier können Sie nicht mit der Kapselung beginnen. Im Folgenden werde ich erklären, warum.
Haftungsausschluss. Dieser Artikel ist kein Aufruf zum Handeln und gibt nicht an, dass es nur eine halbwegs korrekte Möglichkeit gibt, Daten auszublenden. Dieser Artikel soll dem Leser eine möglicherweise neue Perspektive auf die Verkapselung bieten. Es gibt viele Situationen, in denen Zugriffsmodifikatoren vorzuziehen sind, dies ist jedoch kein Grund, über Schnittstellen schweigen zu müssen.
Im Allgemeinen wird die Kapselung als Mittel definiert, um die interne Implementierung eines Objekts vor dem Client zu verbergen, um die Integrität des Objekts zu erhalten und die Komplexität dieser sehr internen Implementierung zu verbergen.
Es gibt verschiedene Möglichkeiten, um diese Verschleierung zu erreichen. Einer ist die Verwendung von Zugriffsmodifikatoren, der andere ist die Verwendung von Schnittstellen (Protokolle, Header-Dateien, ...). Es gibt andere knifflige Funktionen, aber der Artikel handelt nicht von ihnen.
Zugriffsmodifikatoren scheinen auf den ersten Blick mächtiger zu sein, wenn es darum geht, die Implementierung zu verbergen, da sie die Kontrolle über jedes Feld einzeln geben und mehr Zugriffsoptionen bieten. In der Realität ist dies teilweise nur eine Abkürzung zum Erstellen mehrerer Schnittstellen zur Klasse. Zugriffsmodifikatoren bieten Möglichkeiten, die nicht breiter sind als Schnittstellen, da sie sich bis auf ein Detail ausdrücken. Über sie unten.
Feldsichtbarkeit, die durch verschiedene Zugriffsmodifikatoren in Java angezeigt wird.Das folgende Code-Snippet zeigt eine Klasse mit Zugriffsmodifikatoren auf Methoden und entsprechende Darstellungen in Form von Schnittstellen.
public class ConsistentObject { public void methodA() { } protected void methodB() { } void methodC() { } private void methodD() { } } public interface IPublicConsistentObject { void methodA() { } } public interface IProtectedConsistentObject: IPublicConsistentObject { void methodB() { } } public interface IDefaultConsistentObject: IProtectedConsistentObject { void methodC() { } }
Protokolle haben mehrere Vorteile. Es genügt zu erwähnen, dass dies das Hauptmittel für die Implementierung von Polymorphismus in OOP ist, der viel später als möglich Neuankömmlinge erreicht.
Die einzige Schwierigkeit, die mit den Protokollen verbunden ist, besteht darin, dass Sie den Prozess der Objekterstellung steuern müssen. Das Generieren von Vorlagen ist genau erforderlich, um gefährlichen Code, der bestimmte Typen enthält, vor reinem Code zu schützen, der mit Schnittstellen zusammenarbeitet. Wenn wir diese einfache Regel einhalten, erhalten wir dieselbe Kapselung wie bei der Verwendung von Qualifikationsmerkmalen, gleichzeitig erhalten wir jedoch mehr Flexibilität.
Solcher Code in C #
public class DataAccessObject { private void readDataFromFixedSource() {
entspricht dem für die Fähigkeiten des Kunden.
public class DataAccessObjectFactory { public IDataAccessObject createNew() { return new DataAccessObject(); } } public interface IDataAccessObject { byte[] getData(); } class DataAccessObject: IDataAccessObject { void readDataFromFixedSource() {
Aufgrund der Existenz von Zugriffsmodifikatoren werden Anfänger für eine sehr lange Zeit nicht über Schnittstellen Bescheid wissen. Aus diesem Grund nutzen sie nicht die tatsächliche Leistung der PLO. Das heißt, es gibt eine gewisse Substitution von Begriffen. Zugriffsmodifikatoren sind zweifellos ein Attribut von OOP, aber sie ziehen auch die Decke von Schnittstellen, die OOP viel stärker öffnen.
Darüber hinaus können Sie über die Schnittstellen bewusst auswählen, welche Funktionen ein Client von einem Objekt erhalten kann. Das heißt, wir haben die Möglichkeit, völlig unabhängige Protokolle für verschiedene Clients bereitzustellen, während Modifikatoren nicht zwischen Clients unterscheiden. Dies ist ein großes Plus für Schnittstellen.