Objektorientierte Programmierung umwandeln!

PeterShaw77

Mitglied
Hallo,
mich würde interessieren ob es eine möglichkeit gibt ein Spiel das mithilfe Objektorientierter Programmierung geschrieben wurde, umzuwandeln in eine "normale" Programmierung d.h. ohne den Befehl class(). Leider konnte ich dazu bisher nichts finden. Über eine antwort freue ich mich sehr Vielen Dank!
MFG
 
umzuwandeln in eine "normale" Programmierung
Lol. 🙂
Du meinst: in eine prozedurale Programmiersprache oder eine funktionale Sprache? In welche _konkrete_ Sprache willst du denn übersetzen?
Das geht schon, du musst aber die Konzepte wie Polymorphie/Vererbung/dynamic-Dispatch, die dir eine objektorientierte Plattform wie die JVM mitbringt, dann selber lösen per struct-Vererbung (wenn man in C denkt) und über vtables, etc.
Generell macht sowas überhaupt keinen Sinn.
 
Da wir uns hier in einem Java Forum befinden geht es um Java, also ein mit Java programmiertes Spiel (mit objektorientierter programmierung) in ein java spiel (ohne objektorientierter programmierung) umwandeln. Ob es Sinn macht oder nicht wurde nicht gefragt.
 
Da wir uns hier in einem Java Forum befinden geht es um Java
Meine Frage war ja auch nicht, was die Quellsprache ist, sondern was die Zielsprache ist.
Denn Java nach Java zu übersetzen, macht noch viel weniger Sinn und ist auch nicht der erste Gedanken, den man als Antwortender hat, auf solch eine Frage.
Und als Antwort: Ja, es geht, ist aber natürlich mit sehr viel Aufwand verbunden, weil du _alle_ objektorientierten Aspekte in prozeduralen Code übersetzen musst. Aber ganz ohne "class" geht es überhaupt nicht.

Generell hilft es zur Einordnung und Verständnis des Problems immer, den eigentlich Grund zu nennen, _warum_ du soetwas machen willst und wem damit geholfen sein soll.
 
Meine Frage war ja auch nicht, was die Quellsprache ist, sondern was die Zielsprache ist.
Denn Java nach Java zu übersetzen, macht noch viel weniger Sinn und ist auch nicht der erste Gedanken, den man als Antwortender hat, auf solch eine Frage.
Meine Frage war auch nicht ob es Sinn macht, wobei ich glaube dass du die eigentlich Frage immernoch nicht verstanden hast oder verstehen willst.
 
Okay, dann als Antwort auf deine Frage:
ob es eine möglichkeit gibt ein Spiel das mithilfe Objektorientierter Programmierung geschrieben wurde, umzuwandeln in eine "normale" Programmierung d.h. ohne den Befehl class().
Nein, das ist nicht möglich, denn in Java wird ausführbarer Code immer als Methoden innerhalb einer Klasse definiert.
Du kannst also nicht ohne den "Befehl" class auskommen. Das ist in Java schlichtweg nicht möglich.
Was du aber machen kannst ist, auf Polymorphie/Vererbung und dynamic Dispatch (virtuelle Methoden) zu verzichten, indem du alle Methoden als "static" deklarierst.
 
d.h. ohne den Befehl class()
Also class würde ich nicht als Befehl sondern lediglich als Schlüsselwort bezeichnen.

Und nein, ein Java Programm braucht immer mindestens ein Mal das Schlüsselwort class.

Und sobald man komplexere Datentypen hat, dann geht es eh nicht ohne Instanzen. Java kennt als komplexen Datentypen nur class. Es gibt keine struct oder so. (Ok, es gibt Spezielle Klassen wie enums und die neuen Records wohl auch...)
Wenn du „Java aber nicht objektorientiert“ sein willst, dann müsstest du definieren, was du darunter genau verstehst.
 
Also class würde ich nicht als Befehl sondern lediglich als Schlüsselwort bezeichnen.

Und nein, ein Java Programm braucht immer mindestens ein Mal das Schlüsselwort class.

Und sobald man komplexere Datentypen hat, dann geht es eh nicht ohne Instanzen. Java kennt als komplexen Datentypen nur class. Es gibt keine struct oder so. (Ok, es gibt Spezielle Klassen wie enums und die neuen Records wohl auch...)
Wenn du „Java aber nicht objektorientiert“ sein willst, dann müsstest du definieren, was du darunter genau verstehst.
Vielen Dank erstmal
ich habe mir vorgestellt ein einfaches Spiel wie beispielsweiße Flappy Bird, Doodle Jumb etc. in prozeduraler programmierung zu schreiben
 
ich habe mir vorgestellt ein einfaches Spiel wie beispielsweiße Flappy Bird, Doodle Jumb etc. in prozeduraler programmierung zu schreiben
Was hat das denn jetzt etwas damit zu tun, ein in einer objektorientierten Sprache (also konkret Java) programmiertes Spiel in "nicht-objektorientiert" Java zu übersetzen?
Du willst also kein existierendes Programm mit existierendem Java-Quellcode nach "nicht-objektorientiert" Java übersetzen, sondern eine ganz neue Anwendung (neuer Quelltext - nicht, dass das Thema der Anwendung selbst neu ist) bauen?
Das geht natürlich auch, ja.
Du kannst in Java prozedural programmieren, brauchst aber mindestens eine (Main)-Klasse.
 
Was hat das denn jetzt etwas damit zu tun, ein in einer objektorientierten Sprache (also konkret Java) programmiertes Spiel in "nicht-objektorientiert" Java zu übersetzen?
Du willst also kein existierendes Programm mit existierendem Java-Quellcode nach "nicht-objektorientiert" Java übersetzen, sondern eine ganz neue Anwendung (neuer Quelltext - nicht, dass das Thema der Anwendung selbst neu ist) bauen?
Das geht natürlich auch, ja.
Du kannst in Java prozedural programmieren, brauchst aber mindestens eine (Main)-Klasse.
Danke damit hat sich auch schon alles geklärt.
 
Also generell würde ich aber - so wie es @httpdigest schon gemacht hat - die Sinnhaftigkeit hinterfragen.

Das ist keine sinnvolle Übung, macht die Entwicklung nicht einfacher und führt eher zu falschen Herangehensweisen.

Gerade bei so einem Spiel braucht Du ja Strukturen um die Daten zu speichern, brauchst ggf. eine GUI ....
Des Weiteren ist die Gefahr sehr groß, Code zu schreiben der schwer überblickt und gewartet werden kann. Das führt zu deutlich mehr Frust und Problemen bei der Entwicklung.

Du kannst es natürlich gerne angehen und es probieren. Ich will es Dir nicht ausreden - aber auch in meinen Augen macht es nicht viel Sinn.
 
Mal ein Schwank aus dem Studium:
Wir haben ja zuerst C gelernt (also rein prozedural) und dann hatten wir eine Java-Vorlesung. Und um uns Objektorientierung etwas schmackhafter zu machen hat er uns mal von seinen eigenen Anfängen erzählt. Er hatte irgendwann mal ein Programm geschrieben - rein prozedural - und das Programm war am Ende ca. 30.000 Zeilen lang.
Und um Objektorientierung mal auszuprobieren, hat er das Programm noch mal geschrieben. Also von prozedural nach objektorientiert umgeschrieben. da waren es nur noch 5.000 Zeilen Code.

Also die Codemenge um Faktor sechs reduziert.

Das nur mal als kleine Anmerkung für den TS, was ihn in etwa erwarten könnte. Ich denke, man darf daraus auch ganz ungestraft die Folgerung ziehen, daß das Umschreiben eines Programms von objektorientiert nach prozedural wahrscheinlich etwa sechsmal so viel Code produzieren wird. Womöglich sogar weitaus mehr.
Mit allen Nachteilen, die prozedurale gegenüber objektorientierter Programmierung so mitbringt. Vorteile vermag ich nicht zu erkennen.
 
Naja, das ist auch ansichtssache... Da hat beides durchaus seine Daseinsberechtigung. Java ist nun halt einfach Objektorientiert. Das das jetzt zwangsläufig einfacheren oder besseren Code gibt wage ich zu bezweifeln. Man kann sich ein Beispiel immer so auslegen wie es einem passt. z.B.
 
Nur aus Neugierde: Wie würde man denn rein prozedural, also ohne eine der Klassen von z.B. Swing, eine GUI programmieren, die über die Konsole hinausgeht?
 
In Java gar nicht(*). Im Java Framework ist halt alles in Klassen unterteilt und da braucht es in der Regel die Erstellung von neuen Objekten.

(*) Das mag so nicht zwingend richtig sein. Es mag evtl. noch Möglichkeiten geben wie z.B. die Nutzung von externen Libraries und JNI um dies zu nutzen. Aber das ist mit der größte Quatsch.
 
Ich denke gerade an DOS und Turbo Pascal zurück. Da gab es ja quasi eine auf ASCII-Zeichen basierende GUI mit Fenstern und so.
 
Es gibt durchaus im C Umfeld schöne GUI Libraries, allen voran Nuklear, die man z.B. per LWJGL 3 auch einfach nutzen kann. Nuklear ist dabei sogar unabhängig von jeglichem Rending, man muss also nur eine Handvoll Callbacks implementieren (mit OpenGL, Vulkan, Metal, oder einfach BufferedImage bzw. Java2D Operationen).
 
Es gibt durchaus im C Umfeld schöne GUI Libraries, allen voran Nuklear, die man z.B. per LWJGL 3 auch einfach nutzen kann. Nuklear ist dabei sogar unabhängig von jeglichem Rending, man muss also nur eine Handvoll Callbacks implementieren (mit OpenGL, Vulkan, Metal, oder einfach BufferedImage bzw. Java2D Operationen).
Muss ich damit nicht ebenfalls Klassen verwenden, nämlich die von LWJGL?
 
Die Frage ist - was ist Objektorientierung? Wenn ich alles in statischen Methoden und Variablen mache, verwende ich immer noch Klassen - aber Objektorientiert ist es nicht.
 
Die Frage ist auch: Darf ich fremde Klassen nutzen und soll nur mein Programm nicht objektorientiert aufgebaut sein? Das geht dann natürlich auch. Dann nutze ich Dinge wie JFrame und so ohne aber selbst meine Klasse als Instanz zu erstellen.

Dann könnte man sich noch überlegen, ob anonyme Klassen zugelassen sind oder nicht. Und Lambda Ausdrücke (Keine Klasse, aber es wird dann ja ein funktionales Interface implementiert bei den Listeners. Das wäre ggf auch etwas Objekt orientiert. Aber Methoden Referenzen sollten dann durchaus gehen ...

Dann könnte man auch eine Oberfläche mit Swing aufbauen oder so...

Aber was zerbrechen wir uns hier über sowas den Kopf? Den Sinn sehe ich noch nicht wirklich. Klar: Objektorientierung führt nicht automatisch zu gutem Code oder so, aber es gibt gewisse Paradigmen, die es ermöglichen. Das führt auch nicht zwangsläufig zu weniger Codezeilen. (1/6 des codes -> da muss dann ja extrem viel doppelt gewesen sein. Da ist dann eher der Unterschied: Einmal Copy & Paste Programmierung mit viel doppeltem Code und zum anderen mal etwas ans Refactoring gesetzt 🙂 )
 
Der Punkt ist - in Java nicht Objekt-Orient zu programmieren, ist eigentlich nie sinnvoll und führt fast immer zu Chaos, weil die Sprach-Konstrukte auf Objekt-Orientierung ausgelegt sind. Das heißt nicht das eine prozedurale Programmierung per se schlechter ist - aber die dann bitte in einer Sprache (wie z.B. C), die dafür ausgelegt ist und dort die entsprechenden Konstrukte mitbringt. Das ist wie "Ist ein Hammer oder ein Schraubenzieher besser". Wenn ich einen Nagel einschlagen will, geht das vielleicht auch mit einem Schraubenzieher, aber sinnvoll ist das nicht. Umgekehrt, wenn ich eine Schraube reindrehen will, sollte ich eher keinen Hammer nehmen. Tool und Aufgabe müssen zusammenpassen.
 

Zurück
Oben