AHK Benutzerobjekte und Klassen - Grundbegriffe

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :| :mrgreen: :geek: :ugeek: :arrow: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbup: :thumbdown: :salute: :wave: :wtf: :yawn: :facepalm: :bravo: :dance: :beard: :morebeard: :xmas: :HeHe: :trollface: :cookie: :rainbow: :monkeysee: :monkeysay: :happybday: :headwall: :offtopic: :superhappy: :terms: :beer:
View more smilies

BBCode is ON
[img] is OFF
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: AHK Benutzerobjekte und Klassen - Grundbegriffe

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by BoBo » 21 Feb 2018, 05:28

Hier kommt doch lediglich der immense vorteil des englischen zum tragen (was auch dessen globale verbreitung so erleichtert): ein wort mit mehreren (kontext-sensitiven) bedeutungen - im deutschen viele worte mit jeweils spezifischer bedeutung. Letzteres mag zu blütezeiten der literatur "dem land der dichter und denker" zugute gekommen sein, doch im nachkriegsgefüge und der anschließenden anglisierung der wirtschaft/forschung erledigt sich auch die entwicklung "eigener" begrifflichkeiten. So what, shit happens *lol*

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by just me » 21 Feb 2018, 04:49

Na ja, Schnittstelle ist in der Programmierung ein deutscher Fachbegriff mit einer bestimmten Bedeutung. Der Begriff ist auch schon vor den seligen OOP-Zeiten erfunden worden (Stichwort: Modulare Programmierung). Ich kann deshalb keinen Grund dafür erkennen, ihn nicht zu verwenden, zumal Objekte im Kern auch nur Softwaremodule sind.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by nnnik » 21 Feb 2018, 04:27

Ja sollte man meinen. Aber jeder Begriff hat indirekte implikationen die durch die Bedeutung des Wortes festgehalten werden. So impliziert Schnittstelle mit Stelle eine Position.
Wenn man einen Position modellieren möchte was macht man da? Verschiebt man sie? Man kann nur Materialien modellieren. Es klingt einfach nur schwachsinnig. Über die Aktion der Schnittstelle bereitstellen wollen wir gar nicht reden.
Im Gegensatz dazu haben wir das englische Wort Interface, was ich hier mal mit Fläche dazwischen übersetze. Ja man modelliert eine Fläche und hier kann Fläche sogar zusätzlich Gesicht bedeuten - doppelt gut. expose an interface bedeutet dann so viel wie sein Gesicht der Welt zeigen.
OK ich könnte mich jetzt hier problemlos begründet mehrere Stunden über das Wort Schnittstelle aufregen, aber ich werde es einfach sein lassen.

Es gibt einfach keine Übersetzung für das Wort Interface im Deutschen.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by just me » 21 Feb 2018, 03:49

Moin,

in allen Sprachen gibt es Begriffe, die nur im jeweiligen Kontext eine bestimmte Bedeutung haben. Im Kontext Programmierung ist für mich Schnittstelle die exakte Übersetzung von Interface. Die Schnittstelle legt fest, wie Softwarekomponenten miteinander kommunizieren können (z.B. wie man an die hinter einer Schnittstelle liegenden Daten kommt).

Siehe auch: Schnittstelle (Objektorientierung)

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by nnnik » 20 Feb 2018, 18:19

ich glaube es ist leichter einfach die Englischen Fachwörter zu übernehmen. Zudem überzeugt mich bereitstellen auch nicht wirklich, obwohl es den Zusammenhang schon besser trifft.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by gregster » 20 Feb 2018, 17:08

Man spricht häufig von "Schnittstelle bereitstellen" bzw. "wird bereitgestellt", aber das hängt vom Zusammenhang ab. Wörtliche Übersetzungen sind häufig nicht zielführend (wobei teilweise im Dt. auch von "Schnittstelle exponieren" gesprochen wird, wenn der Autor es drauf anlegt). Aber das ist ein generelles Problem/Thema.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by nnnik » 20 Feb 2018, 17:01

Interface ist so ziemlich der perfekte Begriff für ja ein Obektinterface.
Viele der Implikationen die man von dem Begriff Interface ableiten kann treffen auf diese eben genau zu.
Bei Schnittstelle geht das alles verloren. Und zu dem gibt es die Aktion "expose an Interface". Auf die wieder das gleiche zutrifft wie auch auf den Begriff selber.
Deutsch kann da einfach leider nicht mithalten. "eine Schnittstelle freilegen" :sick: :sick: :sick: :sick: :sick: :sick:

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by BoBo » 20 Feb 2018, 16:43

Bedauerlicherweise übersetzt Tante Google es aber 1:1 als "Objektschnittstelle" :silent:
http://context.reverso.net/%C3%BCberset ... +interface
Und anderweitig wird schlicht fachgedeutscht ...
https://www.itwissen.info/Englisch/OB
https://www.itwissen.info/Object-Interf ... rface.html
... wogegen eigentlich auch nichts spricht.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by nnnik » 20 Feb 2018, 14:37

Nein nicht Graphical user interface mehr Objekt Interface.
Schnittstelle ist das nächste und auch der Grund warum ich nicht gerne OOP ins Deutsche Übersetze.
Interface hat mehrere Bedeutungen welche alle auf OOP passen. Schnittstelle ist tatsächlich nicht ansatzweise so schön wie Interface.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by BoBo » 20 Feb 2018, 13:55

nnnik wrote:Falls jemand eine zufriedenstellende Übersetzung für Interface kennt würde ich die gerne hier sehen.

Auf die Gefahr hin die Frage falsch zu verstehen:
(Grafische Benutzer) Schnittstelle = (Graphical User) Interface ?

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by nnnik » 20 Feb 2018, 13:19

Ich habe halt im Gegensatz zu just me die Fachbegriffe nicht übersetzt.
Nur die Grundlegenden Begriffe existieren im Deutschen. Falls jemand eine zufriedenstellende Übersetzung für Interface kennt würde ich die gerne hier sehen.

Re: AHK Benutzerobjekte und Klassen - Grundbegriffe

Post by just me » 20 Feb 2018, 06:35

So, ich erkläre das jetzt erst einmal für fertig. Es ist ein spannendes Thema und ich habe bei der Ausarbeitung auch noch etwas dazugelernt, weil ich Dinge hinterfragt bzw. ausprobiert habe, von denen ich zu wissen glaubte, wie sie (nicht) funktionieren.

Für Korrekturen, Änderungs- oder Ergänzungswünsche bin ich offen.

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by DigiDon » 13 Feb 2018, 11:24

Gute Idee! Ich möchte gern darüber Kenntnisse erwerben.
Scheint sehr interessant :thumbup:

Ich hoffe dass, jemand das auf English einmal übersetzen wird ;)
(Mein Deutsch ist sehr begrenzt)

Aber ich werde bald versuchen, das zuerst zu verstehen. Es wäre eine gute Herausforderung! ;)

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by just me » 11 Feb 2018, 04:30

Klassen - Subklassen:

Klassen können auch 'eingebettete' Subklassen enthalten:

Code: [Select all]GeSHi © Codebox Plus

Class MeineKlasse {
Class SubKlasse {
Static SubKlassenVar := "SubKlassenVar"
}
}

Subklassen unterscheiden sich von 'normalen' Klassen nur in einer Hinsicht: Sie sind nicht super-glopbal. Das bedeutet, sie können nicht direkt über den Klassennamen angesprochen werden. Für den Zugriff auf Subklassen muss man ihrem Namen den Namen der übergeordneten Klasse bzw. Instanz voranstellen:

Code: [Select all]GeSHi © Codebox Plus

MeineKlasse.SubKlasse.SubKlassenVar
; oder aus einer Klassenmethode heraus
This.SubKlasse.SubKlassenVar

Sie sind damit ebenfalls 'eingekapselt'. Mehr gibt es hier dazu nicht zu sagen.

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by just me » 11 Feb 2018, 04:29

Klassen - Eigenschaften (Properties):

Die Eigenschaften werden im englischen Original "Properties" genannt. Sie definieren einen Namen für einen Wert, der abgefragt und/oder gesetzt werden kann, ohne dass der Wert in einer Klassen- oder Instanzvariablen gleichen Namens abgelegt wird. Dafür müssen innerhalb der Eigenschaftsdefinition die reservierten Methoden Get (Wert abfragen) und/oder Set (Wert setzen) definiert werden.

Code: [Select all]GeSHi © Codebox Plus

Class MeineKlasse {
Eigenschaft[] { ; Name der Eigenschaft
Get { ; Wert abfragen
Return ...
}
Set { ; Wert setzen
...
Return ...
}
}
}

Die Dokumentation sagt dazu, dass sowohl beide als auch nur eine dieser Methoden definiert werden kann. Sie enthält dazu zwar einen Warnhinweis, ich möchte den hier aber noch einmal deutlich betonen:
Achtung: Wenn man die Methode Set nicht definiert, wird die Eigenschaft bei einer Wertzuweisung wie Klasse.Eigenschaft := "Bingo" in eine normale Instanzvariable mit dem zugewiesenen Wert umgewandelt. Das bedeutet, bei der nächsten Abfrage wird die Methode Get nicht mehr aufgerufen.

Jede Abfrage einer Eigenschaft wie

Code: [Select all]GeSHi © Codebox Plus

Wert := Instanz.Eigenschaft
ruft die interne Methode Get, jede Wertzuweisung wie

Code: [Select all]GeSHi © Codebox Plus

Instanz.Eigenschaft := "Wert"
ruft die interne Methode Set auf. Im Fall von Set wird der zugewiesene Wert in eine Variable mit dem reservierten Namen Value gestellt und ist so innerhalb von Get verfügbar.

Beim Abfragen und Zuweisen von Eigenschaftswerten können auch zusätzliche Parameter übergeben werden. Dafür hängt man eine Parameterliste eingeschlossen in eckige Klammern [...] direkt an den Eigenschaftsnamen an:

Code: [Select all]GeSHi © Codebox Plus

Class MeineKlasse {
Eigenschaft[Param1, Param2, Param3] { ; Name der Eigenschaft und Parameterliste
Get { ; Wert abfragen
...
}
Set { ; Wert setzen
...
}
}
}
Auf diese Parameter kann dann in Get und Set über die in der Parameterliste definierten Namen zugrgriffen werden. Die Zugriffe auf die Eigenschaft sehen dann so aus:

Code: [Select all]GeSHi © Codebox Plus

Wert := Instanz.Eigenschaft[P1, P2, P3] ; Abfrage
; bzw
Instanz.Eigenschaft[P1, P2, P3] := "Wert" ; Zuweisung
Wenn keine Parameter definiert werden, folgt dem Eigenschaftsnamen entweder ein leeres Klammerpaar [] oder auch 'gar nichts'. Die beiden folgenden Eigenschaftsdefinitionen sind deshalb gleichwertig:

Code: [Select all]GeSHi © Codebox Plus

Class MeineKlasse {
Eigenschaft1[] { ; Name der Eigenschaft, keine Parameter
...
}
Eigenschaft2 { ; Name der Eigenschaft, keine Parameter
...
}
}

Eigenschaften haben eine (für mich) entscheidende Einschränkung. Sie haben keine eigenen Bereiche, in denen Werte abgelegt werden können. Das bedeutet, die Methoden Get und Set können sich keine Variablen teilen, auf die beide zugreifen können. Wenn man in der Methode Set einen Wert speichern will, muss man deshalb dafür eine Instanzvariable der umgebenden Klasse / Instanz (normalerweise This) bemühen.

Beispiel:

Als Beispiel soll eine Klasse für RGB-Farbwerte herhalten. Sie übernimmt (speichert) einen kompletten RGB-Wert und stellt die einzelnen Farbanteile für Rot, Grün und Blau dynamisch über 'Eigenschaften' zur Verfüpgung, ohne dass diese Werte einzeln in der Klasse abgelegt werden. Über die Eigenschaften lassen sich die einzelnen Farbanteile auch setzen.

Code: [Select all] [Expand]GeSHi © Codebox Plus

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by just me » 11 Feb 2018, 04:27

Klassen - Methoden - Destruktor: __Delete():

Der Destruktor wird dann aufgerufen, wenn man eine Instanz freigibt / zerstört / destruiert, wie z.B.

Code: [Select all]GeSHi © Codebox Plus

Instanz := ""
Das wird allerdings nur in seltenen Fällen gebraucht. Die 'normalen' Speicherbereiche einer Instanz werden automatisch freigegeben. Ich beschränke mich deshalb hier darauf, dass die Methode mit dem dafür reservierten Namen __Delete() bei Bedarf ebenfalls in der Basisklasse definiert werden muss:

Code: [Select all]GeSHi © Codebox Plus

Class BasisKlasse {
__Delete() {
MsgBox, %A_ThisFunc%
}
}
Instanz := New BasisKlasse
; ...
Instanz := "" ; gibt die Instanz frei und ruft die Methode __Delete() der Basisklasse auf

Im Gegensatz zum Konstruktor __New() können dem Destruktor __Delete() keine zusätzlichen Parameter übergeben werden.

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by just me » 11 Feb 2018, 04:25

Klassen - Methoden - Konstruktor: __New():

Wie bereits oben gesagt, wird eine neue Instanz über das Schlüsselwort New erstellt (oder auch konstruiert). Im einfachsten Fall werden der Instanz dabei nur eine Referenz auf die Basisklasse übergeben und - so vorhanden - die in der Basisklasse vordefinierten Instanzvariablen erstellt. Wenn die Instanzvariablen für unterschiedliche Instanzen einer Basisklasse unterschiedliche Werte haben sollen, müsste man diese anschließend einzeln setzen, z.B. per

Code: [Select all]GeSHi © Codebox Plus

Instanz.InstanzVariable1 := "WertFürDieseInstanz"

Das ist recht unbequem, und deshalb gibt es die reservierte 'Konstruktionsmethode' __New(). Die muss man in der Basisklasse definieren. Sie wird dann immer aufgerufen, wenn eine neue Instanz per Newabgeleitet wird. Normalerweise nutzt man das, um der neuen Instanz Parameter zu übergeben, deren Werte sich für unterschiedliche Instanzen unterscheiden. Die werden dann in Instanzvariablen abgelegt und können so innerhalb der Instanz genutzt werden. Die so erstellten Instanzvariablen müssen in der Basisklasse nicht vordefiniert werden, man kann es aber trotzdem tun. Die Parameter werden übergeben, indem man sie eingeschlossen In Klammern ( ... ) direkt an den dem Schlüsselwort New folgenden Klassennamen anhängt:

Code: [Select all]GeSHi © Codebox Plus

Instanz := New BasisKlasse(Param1, Param2, Param3)

Ein schlichtes Beispiel:

Code: [Select all] [Expand]GeSHi © Codebox Plus

Jede abgeleitete Mitarbeiterinstanz erlaubt so den Zugriff auf die für alle Mitarbeiter dieser Firma identischen Firmendaten über die Klassenvariablen und den Zugriff auf die persönlichen Daten des Mitarbeiters über die Instanzvariablen.

Man kann innerhalb des Konstruktors auch prüfen, ob die übergebenen Parameter logisch konsistent sind, z.B. einen bestimmten Aufbau haben oder innerhalb eines bestimmten Wertebereichs liegen. Stellt man Fehler fest, kann man das Erstellen einer neuen Instanz verhindern, indem man aus dem Konstruktor per Return Anweisung einen beliebigen Wert zurückgibt:

Code: [Select all]GeSHi © Codebox Plus

Class BasisKlasse {
__New(Param1, Param2, Param3) {
Fehler := False
; ...
; Fehlerprüfung
; ...
If (Fehler)
Return 0 ; damit wird das erstellen der neuen Instanz verhindert
}
}

Re: AHK Objekte und Klassen - Grundbegriffe (Baustelle)

Post by just me » 11 Feb 2018, 04:22

Klassen - Methoden - Allgemeines:

Methoden sind im Printip in der Klasse enthaltene Funktionen, die auf die Klassendaten zugreifen können, ohne dass die als Parameter übergeben werden müssen. Man kann den Methoden aber wie normalen Funktionen zusätzliche Parameter übergeben. Die Definition sieht wie eine normale Funktionsdefinition aus, sie ist aber in die Klassendefiniton eingebettet:

Code: [Select all]GeSHi © Codebox Plus

Class MeineKlasse {
Static KlassenVar := "KlassenVar"
Methode() {
;... Befehle
}
}
Beim Aufruf wird - wie bei den Variablen - der Objektname gefolgt von einem Punkt dem Methodennamen vorangestellt. Dem Methodennamen folgen direkt öffnende und schließende Klammern, zwischen denen Parameter angegeben werden können:

Code: [Select all]GeSHi © Codebox Plus

MeineKlasse.Methode()

Wie kommt nun die Methode an die Klassendaten?

Dafür wird den Objektmethoden als erster Parameter immer eine Referenz auf das Objekt übergeben. Wir betrachten dafür erst einmal, wie die vorstehende Klassendefinition in 'normaler' Objektsyntax aussehen würde:

Code: [Select all]GeSHi © Codebox Plus

Global MeineKlasse := {KlassenVar: "KlassenVar", Methode: Func("Methode")}
Methode(Objektreferenz, Param1, Param2, ...) {
...
}
Man kann so diesen ersten Parameter klar erkennen.

Bei Klassenmethoden wird das anders gehandhabt. AHK spricht hier von einem "versteckten" oder "verborgenen" Parameter. Ich hatte damit zunächst Vertändnisprobleme, habe dann aber für mich folgende Erklärung gefunden:

Beim Aufruf von Klassenmethoden entfernt AHK den ersten übergebenen Parameter aus der Parameterliste und stellt ihn innerhalb der Methode über den reservierten Variablennamen This zur Verfügung. Der erste Parameter darf deshalb in der Methodendefinition nicht angegeben werden.

Damit kann man innerhalb von Methoden über die Variable This auf die Instanzvariablen zugreifen oder auch andere Klassenmethoden aufrufen:

Code: [Select all] [Expand]GeSHi © Codebox Plus

This ersetzt hier den Objektnamen.

Problematisch wird dieses Verhalten aber, wenn man eine Objektmethode z.B. als Funktion für eine OnMessage() Routine oder eine Callbackfunktion nutzen will. Auch in diesem Fall wird der erste Parameter aus der Liste entfernt und darf deshalb nicht als Funktionsparameter angegeben werden. Er enthält aber dann nicht die Objektreferenz, sondern einen 'normalen' Funktionsparameter. Die Variable This enthält deshalb innerhalb der Methode den Wert des entfernten Funktionsparameters und man kann über sie nicht auf das Methodenobjekt zugreifen.

Man kann dieses 'Fehlverhalten' über die Funktion ObjBindMethod(Objekt, "MethodenName") 'korrigieren'. So wird den 'normalen' Funktionsparamatern wieder die Objektreferenz vorangestellt. Das hat allerdings den Nachteil, dass eine zweite Referenz auf das Objekt erstellt wird, was beim Freigeben des Objekts zu Problemen führen kann. Doch dazu später mehr.

Top