Anwendungsentwicklungsmethodik mit Formularen. Erstellen von GUI-Anwendungen Wie man GUI-Anwendungen in c schreibt

Schönen Tag! In diesem Tutorial erstellen wir Ihre erste GUI-Anwendung in MS Visual Studio. Es wird eine Art "Hello World" für grafische Anwendungen sein. Ich werde gleich sagen, dass die Verwendung von Windows Forms nicht die einzige Möglichkeit ist, grafische Anwendungen (Anwendungen mit einer grafischen Benutzeroberfläche) für C # -Programmierer zu erstellen, aber es ist besser, daraus zu lernen. Und so starten wir Visual Studio.

Gestartet? Dann zum Geschäft! Wir gehen zum Hauptmenü und wählen den Punkt "Datei - Neu - Projekt", wie in der folgenden Abbildung gezeigt.

Im erscheinenden Fenster:

  • Wählen Sie auf der linken Seite „Vorlagen – Visual C# – Windows“;
  • Wählen Sie im Hauptbereich das Element „Windows Forms-Anwendung“;
  • Geben Sie im unteren Teil des Fensters den Namen des Projekts ein und geben Sie seinen Speicherort auf der Festplatte an.

Im Allgemeinen, wie in der Abbildung unten gezeigt.

Haben Sie angegeben, was Sie brauchen? Klicken Sie dann auf die Schaltfläche „OK“. Jetzt sollten Sie so etwas sehen (die Hauptbereiche sind mit Rechtecken hervorgehoben):

In der obigen Abbildung habe ich die Hauptbereiche beschriftet: den Designerbereich (oben links), den Lösungs-Explorer-Bereich (oben rechts) und den Eigenschaftenbereich (unten rechts). Dies sind die Bereiche, mit denen wir am häufigsten arbeiten werden.

Im Designerbereich befindet sich nun ein leeres „Formular“, das sogenannte Fenster, in diesem Fall das Hauptfenster unseres Programms. Der Eigenschaftenbereich zeigt die Eigenschaften des im Designer ausgewählten Elements an, in diesem Fall unser Formular, aber der Lösungs-Explorer-Bereich enthält Projektdateien, einschließlich derjenigen, die sich auf die Formulare (Fenster) des Programms beziehen. Und jetzt ändern wir unser Formular ein wenig und führen diese erste Anwendung aus.

Wählen Sie dazu das Formular im Designer aus (dazu können Sie einfach mit der linken Maustaste auf das Formular klicken) und gehen Sie zum Eigenschaftenblock, in dem wir die Zeile „Text“ finden (das Wort ist Text, das wir suchen es in der linken Spalte), wie in der Abbildung unten gezeigt.

Eigenschaft "Text" des Hauptformulars der Anwendung

Bitte beachten Sie, dass die linke Spalte den Namen (Name der Eigenschaft) und die rechte Spalte seinen Wert anzeigt.

In diesem Fall haben wir es mit einer Texteigenschaft zu tun, und ihr Wert wird im Fenstertitel angezeigt, also fügen wir jetzt etwas Eigenes hinzu, zum Beispiel so etwas wie: "Hauptfenster", wie in der folgenden Abbildung gezeigt:

Jetzt können Sie das Projekt erstellen und ausführen. Gehen Sie dazu in das Hauptmenü und wählen Sie "Build - Build Solution". Und dann starten wir die Anwendung, dazu wählen wir im Hauptmenü den Punkt "Debug - Ohne Debugging ausführen". Als Ergebnis sollten Sie das folgende Fenster sehen.

In der nächsten Lektion werden wir uns die einfache Arbeit mit dem Formulardesigner und das Einrichten von GUI-Elementen ansehen, und diese Lektion ist zu Ende, wir haben die erste grafische Anwendung erstellt, gebaut und gestartet.

C++ ist eine der leistungsstärksten und gefragtesten Programmiersprachen. Jeden Tag werden Hunderte von Anwendungen darauf geschrieben, oft unter Verwendung einer GUI. Das Arbeiten mit Grafiken ist für einen Programmierer jedoch nicht immer bequem - in diesem Fall werden fertige Grafikbibliotheken verwendet. Sie machen die Entwicklung des grafischen Teils von Anwendungen so schnell und bequem wie möglich.

SFML

Qt

Die plattformübergreifende Bibliothek Cocos2D-X wurde entwickelt, um die Entwicklung von Handyspielen zu vereinfachen. Unterstützt dieselben Plattformen wie Qt. Unter den Vorteilen sind die Verfügbarkeit, Benutzerfreundlichkeit und die Erstellung eines separaten Spieledesigners auf der Grundlage der Cocos Creator-Bibliothek zu erwähnen. Die Liste der auf der Engine basierenden Spiele umfasst das weltberühmte BADLAND, das auf allen verfügbaren Plattformen läuft.

Etwas anderes

Wenn Sie beim Erstellen eines Spiels mit Grafiken und Animationen in großen Mengen arbeiten müssen, ist es besser, Unity anstelle von Cocos2D-X zu verwenden. Unity lässt sich nahtlos in Tools wie Photoshop, Maya oder Blender integrieren. In Cocos2D-X werden alle Grafiken extern hinzugefügt und vom Code referenziert.

Es gibt keine Lektionen zu dieser Bibliothek in Runet, aber es gibt einen hervorragenden Englischkurs von den Entwicklern.

Saft

Vielleicht eine der bekanntesten Grafikbibliotheken. GTK+ ist ein Grafik-Framework, das in vielen Systemen weit verbreitet ist. Es wurde ursprünglich als Komponente von GIMP konzipiert, aber in den 20 Jahren seit der Veröffentlichung der ersten stabilen Version hat es in Hunderten von anderen Anwendungen Verwendung gefunden.

Jetzt ist GTK + ein vollwertiges grafisches Framework, das dem gleichen QT in nichts nachsteht. Es unterstützt verschiedene Programmiersprachen und entwickelt sich ständig weiter.

Etwas anderes

Früher wurde die Bibliothek als Alternative zu Qt erstellt, das bezahlt wurde. GTK+ ist eines der wenigen Frameworks, das die Sprache C unterstützt. Die Bibliothek ist plattformübergreifend, aber es gibt die Meinung, dass Programme unter Linux nativer aussehen als unter Windows oder Mac (GTK+ wird sogar von KDE gut unterstützt). Interessanterweise wechselte Wireshark aufgrund einiger plattformübergreifender Probleme zu Qt.

Ein Beispiel des ersten Programms kann auf Wikipedia eingesehen werden.

Weitere interessante Artikel zu C++ finden Sie hier.

Fazit

Oben sind die beliebtesten Technologien für die Arbeit mit GUIs aufgeführt, nicht nur in C++, sondern manchmal auch in anderen Sprachen (z. B. Qt und GTK+). Allerdings sollten Sie immer die Eigenschaften einer bestimmten Technologie berücksichtigen. Schreiben Sie eine Liste der Features Ihrer Anwendung, lesen Sie die Beschreibungen aller Bibliotheken und Frameworks noch einmal und wählen Sie erst dann aus, was wirklich am besten zum Projekt passt.

Letzte Aktualisierung: 26.05.2019

In Xamarin.Forms besteht die visuelle Schnittstelle aus Seiten. Die Seite ist ein Objekt der Klasse Page und nimmt den gesamten Bildschirmbereich ein. Das heißt, was wir auf dem Bildschirm eines Mobilgeräts sehen, ist eine Seite. Eine Anwendung kann eine oder mehrere Seiten haben.

Die Seite akzeptiert einen der Layout-Container als Inhalt, der wiederum standardmäßige visuelle Elemente wie Schaltflächen und Textfelder sowie andere Layout-Elemente enthält.

Nehmen wir das im vorherigen Thema erstellte HelloApp-Projekt (oder erstellen Sie ein neues). Standardmäßig wird die gesamte Schnittstelle in der App-Klasse erstellt, die sich in der Datei App.xaml.cs befindet und die aktuelle Anwendung darstellt:

Sein Standardcode ist:

Verwenden des Systems; mit Xamarin.Forms; mit Xamarin.Forms.Xaml; namespace HelloApp ( öffentliche partielle Klasse App: Application ( public App() ( InitializeComponent(); MainPage = new MainPage(); ) protected override void OnStart() ( // Handle beim Start Ihrer App ) protected override void OnSleep() ( / / Behandeln, wenn Ihre App in den Ruhezustand versetzt wird ) protected override void OnResume() ( // Behandeln, wenn Ihre App fortgesetzt wird ) ) )

Die App-Klasse beginnt mit dem Konstruktor, wo zuerst die InitializeComponent()-Methode aufgerufen wird, die das Objekt initialisiert, und dann die MainPage-Eigenschaft festgelegt wird. Durch diese Eigenschaft legt die App-Klasse die Hauptseite der Anwendung fest. In diesem Fall wird sie durch die HelloApp.MainPage-Klasse definiert, die die Klasse ist, die in den Dateien MainPage.xaml und MainPage.xaml.cs definiert ist.

Aber dieser Weg ist nicht der einzige. Xamarin.Forms ermöglicht Ihnen das Erstellen einer visuellen Schnittstelle entweder mithilfe von C#-Code oder deklarativ mithilfe der XAML-Sprache, ähnlich wie HTML, oder einer Kombination dieser Ansätze.

Erstellen einer Schnittstelle aus C#-Code

Fügen wir dem HelloApp-Projekt eine reguläre C#-Klasse hinzu, die wir StartPage nennen.

Und definieren Sie den folgenden Inhalt in dieser Klasse:

Verwenden von Xamarin.Forms; namespace HelloApp ( class StartPage: ContentPage ( public StartPage() ( Label header = new Label() ( Text = "Hello from Xamarin Forms" ); this.Content = header; ) ) )

Diese Klasse stellt eine Seite dar und erbt daher von der ContentPage-Klasse. Der Konstruktor erstellt ein Label mit Text, der als Inhalt der Seite gesetzt wird (this.Content = header).

Um MainPage als Startseite festzulegen, ändern wir die App-Klasse:

Verwenden von Xamarin.Forms; namespace HelloApp ( öffentliche partielle Klasse App: Application ( public App() ( InitializeComponent(); MainPage = new StartPage(); ) protected override void OnStart() ( // Handle wenn deine App startet ) protected override void OnSleep() ( / / Behandeln, wenn Ihre App in den Ruhezustand versetzt wird ) protected override void OnResume() ( // Behandeln, wenn Ihre App fortgesetzt wird ) ) )

Die MainPage-Eigenschaft zeigt jetzt auf die neu erstellte StartPage.

Es ist auch erwähnenswert, dass Visual Studio eine vorgefertigte Vorlage zum Hinzufügen neuer Seitenklassen mit dem einfachsten Code hat. Um also eine neue Seite hinzuzufügen, müssen Sie beim Hinzufügen eines neuen Elements die Vorlage Inhaltsseite (C#) auswählen:

Diese Klasse wird dem Hauptprojekt der Lösung hinzugefügt (in diesem Fall ist es HelloApp).

Die hinzugefügte Seitenklasse hat den folgenden Code:

Verwenden des Systems; mit System.Collections.Generic; mit System.Linq; mit System.Reflection.Emit; mit System.Text; mit Xamarin.Forms; namespace HelloApp ( public class Page1: ContentPage ( public Page1() ( Content = new StackLayout ( Children = ( new Label ( Text = "Hello Page" ) ) ) ) )

Diese Klasse erbt auch von der ContentPage-Basisklasse und hat fast die gleiche Organisation wie die oben erstellte MainPage-Klasse.

Und auch in der Anwendungsklasse können wir diese Seite als Startseite festlegen:

Verwenden von Xamarin.Forms; Namespace HelloApp ( öffentliche Teilklasse App: Application ( public App() ( InitializeComponent(); MainPage = new Page1(); ) //........... ) )

Ich werde sofort reservieren, dass C ++ meine Lieblingssprache ist, ich schreibe praktisch „seit meiner Kindheit“ darin und ich werde seine Bedeutung als die beste der besten Sprachen zum Schreiben nicht leugnen Programme für jeden Zweck. Außerdem sehe ich keinen Grund, einen weiteren Holivar zu starten oder "Zeiger" zu messen. Dieser Artikel ist nur eine Beschreibung einer schlechten Erfahrung mit der Sprache und erklärt einige ihrer Aspekte, deren Kenntnis anderen Programmierern in Zukunft helfen wird.

Eines Tages stieß ich auf eine sich entwickelnde GUI-Klassenbibliothek. Aus der Sicht von C++ und insbesondere seiner Klassen, Instanzen und Hierarchien scheint diese Sprache dem Konzept der GUI-Steuerung unglaublich nahe zu sein, insbesondere Elementen wie Widgets, Klassenfenstern und Unterfenstern. Die OO-Modelle von C++ und dem Fenstersystem sind jedoch unterschiedlich. C++ sollte eine "statische" Sprache mit Token-Bereich, statischer Typprüfung und während der Kompilierzeit definierten Hierarchien sein. Andererseits sind Fenster und ihre Objekte dynamischer Natur, sie leben normalerweise außerhalb der einzelnen Prozedur oder des Blocks, durch den sie erstellt wurden; Widget-Hierarchien werden weitgehend durch Layout, Sichtbarkeit und Ereignisströme definiert. Die Grundlagen der grafischen Benutzerschnittstelle, wie beispielsweise dynamische und geometrische Fenster- und Steuerungshierarchien und Ereignisfluss, werden nicht direkt von der C++-Syntax oder ihrer Semantik unterstützt. Daher müssen diese Funktionen in C++-GUI-Code repliziert werden. Dies führt zu einer Duplizierung des grafischen Toolkits oder der Window-Manager-Funktionalität, der Code ist „aufgebläht“, wir sind gezwungen, viele der „starken“ Features von C++ aufzugeben (z. B. Typüberprüfung zur Kompilierzeit). Der Artikel enthält einige einfache Beispiele für C++/GUI-„Nichtübereinstimmungen“.

Erstellen Sie keine Konstruktoren (oder verwenden Sie sie zumindest nicht)

Wenn die resultierende Klasse eine virtuelle Methode der übergeordneten Klasse überschreibt, denken Sie daran, dass die Überschreibung nicht wirksam wird, während der Konstruktor der Basisklasse ausgeführt wird. Dies ist besonders ärgerlich, wenn Objekte Widgets anfordern, die auf GUI-Ereignisse reagieren. Angenommen, die Klasse Basic_Window sollte ein Vanilla-Schwarz-Weiß-Fenster auf dem Bildschirm erstellen:

ClassBasic_Window(
allgemein:
Basic_Window(Rect rect) ( gt_create_window(rect,visible,this); )
virtual void handle_create_event() ( set_background(WEISS); )
};

Hier gt_create_window() ist verantwortlich für den Low-Level-Aufruf des grafischen Haupt-Toolkits (z. B. xvt_win_create()). Diese Funktion weist Platz für Instrumentierungsdaten zu, benachrichtigt den Fenstermanager, registriert dieses Objekt als Ereignis-Listener und initialisiert im obigen Beispiel die grafische Ausgabe für das Fenster auf dem Bildschirm.
Angenommen, wir möchten eine Instanz erstellen Basic_Window, aber mit rotem Hintergrund. Normalerweise müssen Sie, um das Verhalten einer Klasse zu ändern, daraus extrahieren und die entsprechenden virtuellen Methoden überschreiben. Wir schreiben:

Klasse RedWindow: public Basic_Window(
virtual void handle_create_event() ( set_background(ROT); )
allgemein:
RedWindow(Rect rect) : Basic_Window(Rect rect) ()
};
redWindow red_window(default_rect);

Aber rotes_fenster erscheint weiß, nicht rot! Erschaffen Rotes Fenster, muss das übergeordnete Objekt zuerst erstellt werden. Nach dem Beenden Basic_Window::Basic_Window(), virtuelle Tische Rotes Fenster wirken, Methode handle_create_event() wird ungültig, und der Konstruktor RotesFenster() durchgeführt. Konstrukteur Basic_Window() registriert ein Grafikwerkzeugobjekt, das sofort beginnt, Ereignisse an das Objekt zu senden (z. B. ein CREATE-Ereignis). Konstrukteur Basic_Window() noch nicht abgeschlossen (nicht garantiert), daher ist die überschriebene virtuelle Methode noch nicht vorhanden. Das CREATE-Ereignis wird also behandelt Basic_Window::handle_create_event(). Virtuelle Tische Rotes Fenster Klassen werden nur erstellt, wenn die Basisklasse vollständig konstruiert ist, dh wenn das Fenster bereits auf dem Bildschirm ist. Das Ändern der Farbe des Fensters in diesem Stadium führt zu einem ärgerlichen Fehler.

Es gibt eine einfache Problemumgehung: Verhindern Sie, dass jeder Konstruktor ein GUI-Toolkit-Objekt registriert. Die Ereignisbehandlung wird so strukturiert, dass das Ende der Initialisierung für abgeleitete Klassen zurückgehalten wird. Es ist sehr verlockend, sich Widgets auf dem Bildschirm als das „Gesicht“ des GUI-Objekts einer Anwendung im Speicher vorzustellen. Wie das obige Beispiel zeigt, ist diese Verbindung zwischen dem Bildschirm und dem C++-Objekt nicht so einfach zu implementieren: Sie werden separat geboren.

Keine syntaktischen Mittel zum Schalten von Ereignissen

Angenommen, die Klassenbibliothek enthält eine Klassen-GUI PictWindow die ein Foto in einem Fenster anzeigt:

Klasse PictWindow(
Bild Bild;
allgemein:
virtual void repaint() ( gt_draw_pict(picture); )
...
};

Wir möchten in einem bestimmten Bereich des Bildes ein kleines Rechteck überlagern. Zu diesem Zweck können wir versuchen, Unterklassen zu bilden PictWindow:


Rectect;
virtual void repaint() ( gt_draw_rect(rect); )
};

Leider, wenn wir instanziieren OvWindow, sehen wir nur ein Rechteck in einem leeren Fenster und kein Bild. Von dem Moment an OvWindow::repaint() definiert neu PictWindow::repaint(), wird die letzte Funktion nicht aufgerufen, wenn das Fenster gezeichnet werden soll. Wir mussten umsetzen OvWindow So:

Klasse OvWindow: public PictWindow(
Rectect;
virtual void repaint() ( PictWindow::repaint(); gt_draw_rect(rect); )
allgemein:
OvWindow(void) : PictWindow()()
};

Konstrukteur OvWindow betont, dass die Methode OvWindow::repaint() müssen wie Konstruktoren auf die Oberklasse verschoben werden. Tatsächlich ruft der Konstruktor des abgeleiteten Objekts den Konstruktor des entsprechenden Objekts von Anfang an auf. repaint() sollte auf seine übergeordnete Methode in der Basisklasse verschoben werden, die sie überschreibt.

Fazit: Schlechte C++ / GUI-Kompatibilität

C++ wurde als "statische" Sprache entwickelt:

  • mit Token-Tracking
  • statische Typprüfung
  • mit statischen Klassenhierarchien
  • keine Müllabfuhr
  • mit einem Nachrichtensystem ohne definierte Kompilierungshierarchien

GUI-Objekte:

  • von dynamischen Objekten geprägt und oft die einzigen ihrer Art
  • neigen dazu, weit über die Grenzen hinaus zu leben, in denen sie geschaffen wurden
  • Hierarchien werden zu einem großen Teil durch den Ablauf von Ereignissen und ihren Ort bestimmt, nicht durch Klassenvererbung
  • Hierarchien werden zur Laufzeit erstellt und zerstört, oft als Reaktion auf unvorhersehbare Benutzeraktionen

C++ ist nicht darauf ausgelegt, dynamische Sicherheit für Messaging und Übertragungen zu unterstützen (mit Ausnahme von Ausnahmen). All dies führt zu einer Duplizierung von grafischen Werkzeugen und Window-Manager-Funktionalität, Code-Wildwuchs, Verwendung unsicherer Funktionen und Aufgabe vieler Stärken von C++.

Schlussfolgerungen

Natürlich sind all diese "Haken" nicht tödlich. C++ ist eine vielseitige und mächtige Sprache und daher in der Lage, alle möglichen Berechnungsalgorithmen auszudrücken. Wenn also eine Anwendung dynamische Funktionen erfordert, wie sie in tcl/tk, Schema/Tk, Nachschrift und ähnliches; Mit C++ können Sie immer so etwas tun. Warum aber nicht eine Sprache verwenden, in der all diese Merkmale vorhanden sind?

Letzte Aktualisierung: 07.10.2019

Eine Schnittstelle stellt einen Referenztyp dar, der einige Funktionen definieren kann – eine Reihe von Methoden und Eigenschaften ohne Implementierung. Dann wird diese Funktionalität durch Klassen und Strukturen implementiert, die diese Schnittstellen verwenden.

Schnittstellendefinition

Das Interface-Schlüsselwort wird verwendet, um eine Schnittstelle zu definieren. In der Regel beginnen Schnittstellennamen in C# mit einem Großbuchstaben I , z. B. IComparable, IEnumerable (die sogenannte ungarische Notation), dies ist jedoch keine Voraussetzung, sondern eher ein Programmierstil.

Was kann eine Schnittstelle definieren? Im Allgemeinen können Schnittstellen die folgenden Entitäten definieren:

  • Eigenschaften

    Indexer

  • Statische Felder und Konstanten (seit C# 8.0)

Schnittstellen können jedoch keine nicht statischen Variablen definieren. Zum Beispiel die einfachste Schnittstelle, die all diese Komponenten definiert:

Interface IMovable ( // Konstante const int minSpeed ​​​​= 0; // Mindestgeschwindigkeit // statische Variable static int maxSpeed ​​= 60; // maximale Geschwindigkeit // Methode void Move(); // Bewegung // Property-String Name ( get; set ; ) // Name des Delegaten void MoveHandler(string message); // Definieren eines Delegaten für das Ereignis // event event MoveHandler MoveEvent; // motion event )

In diesem Fall wird die IMovable-Schnittstelle definiert, die ein sich bewegendes Objekt darstellt. Diese Schnittstelle enthält verschiedene Komponenten, die die Fähigkeiten eines sich bewegenden Objekts beschreiben. Das heißt, die Schnittstelle beschreibt einige Funktionen, die ein sich bewegendes Objekt haben sollte.

Methoden und Eigenschaften einer Schnittstelle dürfen keine Implementierung haben, insofern sind sie näher an abstrakten Methoden und Eigenschaften abstrakter Klassen. In diesem Fall definiert die Schnittstelle eine Move-Methode, die eine Bewegung darstellt. Es hat keine Implementierung, nimmt keine Parameter entgegen und gibt nichts zurück.

Gleiches gilt in diesem Fall für die Name-Eigenschaft. Auf den ersten Blick sieht es aus wie eine automatische Eigenschaft. Aber in Wirklichkeit ist dies eine Eigenschaftsdefinition in einer Schnittstelle, die keine Implementierung hat, keine Auto-Eigenschaft.

Noch ein Punkt bei der Deklaration einer Schnittstelle: Wenn ihre Mitglieder - Methoden und Eigenschaften - keine Zugriffsmodifikatoren haben, der Zugriff jedoch standardmäßig öffentlich ist, da der Zweck der Schnittstelle darin besteht, die Funktionalität für die Implementierung durch ihre Klasse zu definieren. Dies gilt auch für Konstanten und statische Variablen, die in Klassen und Strukturen standardmäßig den Modifikator private haben. In Schnittstellen haben sie standardmäßig den Modifikator public. Und zum Beispiel könnten wir auf die minSpeed-Konstante und die maxSpeed-Variable der IMovable-Schnittstelle verweisen:

Statisch void Main(string args) ( Console.WriteLine(IMovable.maxSpeed); Console.WriteLine(IMovable.minSpeed); )

Aber auch ab C# 8.0 können wir explizit Zugriffsmodifikatoren für Schnittstellenkomponenten angeben:

Interface IMovable ( public const int minSpeed ​​​​= 0; // minimale Geschwindigkeit private static int maxSpeed ​​​​= 60; // maximale Geschwindigkeit public void Move(); geschützter interner String Name ( get; set; ) // Name des öffentlichen Delegaten void MoveHandler(string message); // Definieren eines Delegaten für das öffentliche Ereignisereignis MoveHandler MoveEvent; // Bewegungsereignis )

Ab C# 8.0 unterstützen Schnittstellen Standardimplementierungen von Methoden und Eigenschaften. Das bedeutet, dass wir vollwertige Methoden und Eigenschaften in Schnittstellen definieren können, die eine Implementierung haben, genau wie in gewöhnlichen Klassen und Strukturen. Lassen Sie uns beispielsweise eine Standardimplementierung der Move-Methode definieren:

Schnittstelle IMovable ( // Implementierung der Standardmethode void Move() ( Console.WriteLine("Walking"); ) )

Bei der Implementierung von Standardeigenschaften in Schnittstellen ist die Situation etwas komplizierter, da wir in Schnittstellen keine nicht statischen Variablen definieren können und dementsprechend in Schnittstelleneigenschaften den Zustand eines Objekts nicht manipulieren können. Wir können jedoch auch eine Standardimplementierung für Eigenschaften definieren:

Schnittstelle IMovable ( void Move() ( Console.WriteLine("Walking"); ) // Implementierung der Standardeigenschaft // schreibgeschützte Eigenschaft int MaxSpeed ​​​​( get ( return 0; ) ) )

Es ist erwähnenswert, dass, wenn die Schnittstelle über private Methoden und Eigenschaften verfügt (d. h. mit dem privaten Modifikator), diese eine Standardimplementierung haben müssen. Dasselbe gilt für alle statischen Methoden und Eigenschaften (nicht unbedingt privat):

Schnittstelle IMovable ( public const int minSpeed ​​​​= 0; // minimale Geschwindigkeit private static int maxSpeed ​​​​= 60; // maximale Geschwindigkeit // finde die Zeit, die benötigt wird, um die Distanz mit der Geschwindigkeit static double GetTime(double distance, double speed ) = > Distanz / Geschwindigkeit; static int MaxSpeed ​​( get ( return maxSpeed; ) set ( if (value > 0) maxSpeed ​​​​= value; ) ) ) class Program ( static void Main(string args) ( Console.WriteLine (IMovable.MaxSpeed); IMovable.MaxSpeed ​​= 65;Console.WriteLine(IMovable.MaxSpeed);double time = IMovable.GetTime(100, 10);Console.WriteLine(time); ) )

Modifikatoren für den Schnittstellenzugriff

Schnittstellen haben wie Klassen standardmäßig die interne Zugriffsebene, was bedeutet, dass eine solche Schnittstelle nur innerhalb des aktuellen Projekts verfügbar ist. Aber mit dem öffentlichen Modifikator können wir die Schnittstelle öffentlich machen:

Öffentliche Schnittstelle IMovable ( void Move(); )

Es ist erwähnenswert, dass Visual Studio über eine spezielle Komponente zum Hinzufügen einer neuen Schnittstelle in einer separaten Datei verfügt. Um dem Projekt eine Schnittstelle hinzuzufügen, können Sie mit der rechten Maustaste auf das Projekt klicken und im erscheinenden Kontextmenü Hinzufügen -> Neues Element... auswählen und im Dialogfeld zum Hinzufügen einer neuen Komponente das Element Schnittstelle auswählen.

Fortsetzung des Themas:
Internet

Eine Halbleiterdiode ist gegenüber ausreichend schnellen Strom- oder Spannungsänderungen inert, da sich nicht sofort eine neue Ladungsträgerverteilung einstellt. Wie...