Seite 2 von 4

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 12:52
von NicTheQuick
Am liebsten mag ich an OOP die Vererbung von Methoden und Eigenschaften und das Überschreiben der selbigen. Es gibt so viele schöne Entwurfsmuster für OOP, mit denen sich tolle Dinge abbilden lassen, die mit einem rein prozeduralen Programmierparadigma nicht möglich sind. Das lässt sich aber auch alles nicht in einem Forumposts erklären. Ich denke, wenn man danach sucht, findet man genügend Gegenüberstellungen der beiden Paradigma, damit man sich seine eigene Meinung bilden kann.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 13:46
von TroaX
Das Problem ist weniger die eigene Meinung, sondern der unterschwellige Zwang, der einem oftmals keine andere Wahl lässt, es einsetzen zu müssen. Natürlich hat OOP auch interessante Vorteile. Für mich ist es eher das Kapseln/Gruppieren. Aber mittlerweile brauch man kaum noch einen Sourcecode zu lesen versuchen, weil dieser einfach bis zur Vergasung totabstrahiert ist und man sich erst mit den Frameworks auseinandersetzen muss, auf denen der Kram basiert.

Ich bin soooo froh, das ich das nicht beruflich machen muss.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 16:59
von Captn. Jinguji
Man sollte sich OOP auf jeden Fall mal angesehen und ein kleines, eigenes Projekt damit gemacht haben, dann erschließt sich der Sinn schon ganz von allein, und der Appetit kommt dann schon beim Essen. Insgeheim schult einen OOP ja implizit auf ein strukturierte(re)s (Lösungs-)Denken, wenn einem das nicht sowieso liegt. Wem's gar nicht liegt, wird es aber durch OOP auch nicht (mehr) beigebracht, diese Leute können woanders viel glücklicher werden und sollten OOP sein lassen.
Es ist eigentlich auch weitgehend egal, mit welcher OOP Sprache man anfängt, "haste eine verstanden, haste alle verstanden"; was aber auch passieren kann: "Wenn Du eine hasst, hasst Du sie alle".

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 19:46
von mk-soft
Eigentlich braucht man kein OOP, aber manchmal hat OOP auch ein kleinen Vorteil. Um es zu vereinfachen, siehe Signatur OOP-BaseClass. Alles nur Macros.

Beispiel zur Anwendung siehe Own Flat Gadgets as Object

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 21:32
von NicTheQuick
Richtig, man braucht kein OOP. Man braucht aber auch keine Hochsprache. Man kann natürlich auch gleich alles in Assembler schreiben.
Je komplexer Projekte werden, desto einfacher wird es sie objektorientiert zu gestalten. Dann muss man sich später keine Gedanken darüber machen welches konkrete Objekt man da gerade hat und welche Funktion man für das aufrufen muss. Stattdessen schreibt man einfach Object\read(100) und schon werden 100 Bytes gelesen. Dabei ist es egal, ob das gerade eine Datei war, ein FIFO, eine Netzwerkverbindung, ein roher Speicherbereich. Vielleicht war es sogar eine virtuelle Datei, die eigentlich noch unentpackt in einer ZIP-Datei liegt oder sich auf einem per WebDAV angebundenen Dateiserver befindet.
Bei Objektorientierung ist das alles egal. Solange es eine Basisklasse gibt, die die Methode read() enthält und alle anderen Klassen sich von ihr ableiten, muss man nicht mehr wissen. Man muss nicht unterscheiden zwischen ReadData() oder ReceiveNetworkData() oder ReadConsoleData() oder ReceiveHTTPMemory() oder oder oder...

Ich finde OOP bringt viele Vorteile, die sich aber erst auswirken, wenn man ausschließlich damit arbeitet. Purebasic ist dafür eben nicht ausgelegt, obwohl man sicherlich alle seine Libraries wunderbar objektorientiert aufbauen könnte.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 01.12.2021 21:38
von jacdelad
Hm, also wie die Wahl zwischen beingin oder Elektro...was mir besser gefällt. Dann vergesse ich Interfaces erstmal wieder.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 28.06.2022 14:12
von Olafmagne
Hallo,
ich habe da noch ein paar Fragen zum Interface:
Der Code von @Stargate ist ja sehr informative,
aber::
Wie definiere ich 'Klassen-Funktionen', also Funktionen, die nicht an ein Objekt, sondern an die Klasse gebunden sind
oder 'Klassen-Variabeln' die an die Klasse gebunden sind, nicht sichtbar sind und intern verwendet werden,
also 'privat' und wie würde ich darauf zugreifen?

Gruss Olaf

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 28.06.2022 14:49
von NicTheQuick
Es gibt keine echten statischen Klassenmethoden bei Interfaces. Das funktioniert nur bei Sprachen, die grundsätzlich auf OOP ausgelegt sind. Und private, geschützte oder öffentlichen Quantifikatoren gibt es auch nicht.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 28.06.2022 14:54
von STARGÅTE
Olafmagne hat geschrieben: 28.06.2022 14:12 Wie definiere ich 'Klassen-Funktionen', also Funktionen, die nicht an ein Objekt, sondern an die Klasse gebunden sind
oder 'Klassen-Variabeln' die an die Klasse gebunden sind, nicht sichtbar sind und intern verwendet werden,
also 'privat' und wie würde ich darauf zugreifen?
Ich kenne mich mit OOP nicht so aus, aber wird das nicht genau so schon von meinem Beispiel gemacht?
Das Interface ist die Klassen und trägt die Methoden (Funktionen). Das Objekt selbst enthält diese Funktionen nicht, sondern nur eine Art Pointer zur Klasse (*Methods).
Die Klassen-Variablen stecken in der Struktur (in meinem Fall X und Y). Diese sind von außen nicht sichtbar, soll heißten du kommst von außen nicht über den Backslash ran. Zugreifen kannst du auf diese Klassen-Variablen aber in den Methoden, wo du ja die Struktur benutzt und nicht das Interface.

Re: Interfaces-Beispiel in der Hilfe korrekt?

Verfasst: 28.06.2022 14:59
von NicTheQuick
@STARGÅTE
Klassen-Funktionen oder statische Methoden sind in der Regel an eine Klasse gebunden und nicht an eine Instanz der Klasse. Das heißt sie können auch nicht mit den Daten der Instanz arbeiten, haben also auch keinen *this-Pointer auf die Daten. Du kannst sie dir eher vorstellen wie eine einfache Procedure im Namespace der Klasse. Solche statischen Methoden sind häufig kleine Helferfunktionen, die eben nichts über die Instanz wissen müssen, sondern lediglich einen Wert umwandeln oder formatieren oder ähnliches.