ProgrammierungiOS Entwickler

Erklären Sie das Prinzip des Zugriffs auf private/protected/internal/public/open in Swift. Wann sollte man jeden dieser Modifikatoren verwenden und mit welchen Fehlern kann man in einem echten Projekt konfrontiert werden?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort

In Swift gibt es fünf Zugriffslevel für die Mitglieder von Typen (Eigenschaften, Methoden usw.) und für die Typen selbst:

  • open — maximaler Grad der Öffentlichkeit. Kann auch außerhalb des Moduls vererbt und überschrieben werden.
  • public — außerhalb des Moduls verfügbar, aber nicht überschreibbar/vererbbar.
  • internal (Standard) — innerhalb des Moduls verfügbar.
  • fileprivate — nur innerhalb der Datei verfügbar.
  • private — nur im Geltungsbereich der Deklaration verfügbar (Extensions sind auch in diesem Scope).

Verwendungsvorschriften:

  • Verwenden Sie private für Logik, die außerhalb der Deklaration nicht sichtbar sein sollte.
  • fileprivate — wenn ein Datenaustausch innerhalb einer Datei erforderlich ist (z. B. zwischen zwei verwandten Extensions).
  • internal — Standard für alles, was im Modul allgemein verfügbar ist.
  • public/open — für APIs, die von anderen Modulen/Frameworks verwendet werden.

Beispiel:

open class MyOpenClass {} public class MyPublicClass {} internal class InternalClass {} fileprivate class FilePrivateClass {} private class PrivateClass {}

Fangfrage

Wie unterscheidet sich open von public bei der Klassendefinition? Warum sind nicht alle public Klassen für die Vererbung verfügbar?

Antwort: open kennzeichnet Klassen/Methoden als für die Überschreibung und Vererbung außerhalb ihres Moduls verfügbar. public öffnet nur den Zugang zur Verwendung, erlaubt aber keine Vererbung außerhalb des Moduls. Einerseits schützt dies die Implementierung vor unerwünschten Änderungen, andererseits öffnet es nur die benötigten Erweiterungspunkte.

public class PublicClass {} open class OpenClass {} // In einem anderen Modul: class InheritFromOpen: OpenClass {} // OK class InheritFromPublic: PublicClass {} // Fehler!

Beispiele für reale Fehler aufgrund mangelnden Verständnisses der Feinheiten des Themas


Geschichte

In einer gemeinsamen Bibliothek wurde eine Klasse als public markiert, und ein externes Projekt versuchte, sie zu erweitern, indem es Methoden überschreibt. Das Projekt ließ sich aufgrund eines fehlerhaften Verständnisses des Unterschieds zwischen public und open nicht kompilieren — dies kostete dem Team eine zusätzliche Woche, um die Schnittstelle anzupassen.


Geschichte

Innerhalb einer Datei wurde versucht, auf eine private Eigenschaft aus einer Extension zuzugreifen — die Eigenschaft war jedoch nicht als fileprivate, sondern als private deklariert. Dies führte zu einem Compilerfehler, der erst bei der Integrationsbuild auffiel.


Geschichte

In einer Anwendung mit mehreren Frameworks wurden alle Typen standardmäßig als internal markiert. Als es erforderlich war, Typen zwischen Modulen zu verwenden, war die Schnittstelle nicht verfügbar — es musste Dutzende von Deklarationen auf public umgeschrieben werden, was zusätzliche Zeit und Tests in Anspruch nahm.