Java ohne Objektorientierung schlimm?

... komplette Frage anzeigen

7 Antworten

Ich hab deinen Quellcode schon in deinen bisherigen Fragen gesehen. Machen wir uns nichts vor, du bist noch Anfänger und hast Objektorientierung wahrscheinlich noch nicht richtig verstanden. Das geht aber vielen Anfängern so. Teilweise wird auch Objektorientierung falsch eingesetzt und dann ist z.B. alles eine statische Methode oder jeder Fliegenschiss kriegt 'ne eigene Klasse. Wenn du Java richtig (!) kannst, dann solltest du dir ein Buch über Entwurfsmuster zulegen (Ich find "Entwurfsmuster von Kopf bis Fuß" aus dem O'Reilly-Verlag gut) und das als nächstes durcharbeiten.

Was bei Java idealerweise in der Main stehen sollte bzw. was da "Best Practise" ist, weiß ich nicht. Aber dort sollte definitiv nicht das ganze Programm drinstehen, tendenziell ist weniger mehr. Wenn Objektorientierung nicht dein Ding ist, dann solltest du dir zumindest angewöhnen, gemeinsam genutzten Code in Funktionen auszulagern. Wenn du Code per Copy & Paste irgendwo mehrfach im Code einfügst oder ähnliche Codestellen mehrmals hast, dann machst du irgendwas falsch.

Wenn wir nur mal dein Snake-Spiel als Beispiel nehmen - angenommen, du überlegst dir morgen, dass dein Spielfeld eine Spalte breiter sein soll - an wievielen Stellen müsstest du den Code ändern? Im Idealfall sollte das eine einzige Zahl im Code sein, die du um Eins erhöhen müsstest. Funktionen und Objektorientierung sind Hilfsmittel, um dieses Ziel zu erreichen.

Antwort bewerten Vielen Dank für Deine Bewertung

Ellenlange Funktionen sind sehr schlechter Stil. Funktionen sollten so kurz wie nur irgend möglich sein. :)

Viele sagen maximal 10 Zeilen pro Funktion, andere sehen es lockerer und sehen das Maximum bei 15 bis 20 Zeilen. Aber es gibt wirklich fast nie einen Grund, darüber hinaus zu kommen. (Ich persönlich halte es - falls möglich und sinnvoll - unter 5 Zeilen pro Funktion!)

Auf der anderen Seite sind ellenlange Zeilen oder sog. Trainwrecks auch nicht gerade sinnvoll, um nicht zu sagen extrem schlechter Stil. Also lagere einige Dinge ruhig in eine extra Variable aus, anstatt zu versuchen, die Zeilenzahl auf Teufel komm raus gering zu halten.

Schicke Funktionen sind kurz, erledigen nur EINE Sache, haben einen aussagekräftigen Namen und sehen mehr oder weniger quadratisch aus.

Ob man ein oder mehrere return-Statements verwendet, ist dann wieder ein anderes Thema. Ich persönlich verwende immer NUR ein einziges return am Ende der Funktion, bis auf ganz wenige Ausnahmen.

Das hängt aber auch stark von der Sprache an sich ab! (Bei C sind mehrere Returns sehr gefährlich, reißen Sicherheitslücken auf, und sollten vermieden werden. Java hat einen GC und C++ hat Scope-basierte Destruktoren, sodass mehrere Returns hier völlig OK sind, wobei sich auch hierbei die Geister scheiden ... aber das ist ein anderes Thema.)

Du solltest niemals über zwei Verschachtelungsebenen hinaus kommen. Am besten siehst du nur eine einzige als erstrebenswert an (das lässt sich aber auch nicht immer einhalten). Eine if-Bedingung innerhalb einer anderen if-Bedingung schreit förmlich danach, in eine weitere Funktion ausgelagert zu werden. :)

Eine Funktion sollte exakt eine einzige (!) Aufgabe erfüllen. Wenn sie mehr tut, dann sollte man über ein Refactoring in zwei oder mehr Funktionen nachdenken.

Und dabei sind wir noch nicht mal bei OOP angelangt. :)

Eine Riesen-Funktion oder -Klasse bezeichnet man im allgemeinen als "Blob", und das ist ein sehr verbreitetes Antipattern (also eine schlechte Angewohnheit).

Fazit: Ja, es ist sehr "schlimm", was du da tust. Zumal du dir damit jegliche Möglichkeit nimmst, effektiv testen zu können.

Aber du bist noch Anfänger und von daher ist das alles überhaupt nicht verwerflich. Es dauert eine Weile, bis sich das Gehirn an OOP gewöhnt hat. Versuche einfach immer weiter zu lernen, und zu Übungszwecken immer schön alles in saubere Klassen zu verpacken! (Aber auch nicht übertreiben und für jeden Futzel eine eigene Klasse bauen!)

So wie dir, geht es auch vielen anderen. Aber das kann man überwinden! Übung macht den Meister.

Viel Erfolg! ;)

Antwort bewerten Vielen Dank für Deine Bewertung

Nachdem das Thema Objektorientierung bereits sehr gut beantwortet wurde gehe ich nur och auf Punkt 2 ein:

Also kann ich in javafx auch die scene und so in der main erstellen

Nein, das geht nicht. In der Main-Methode führst du nur die launch Methode aus, welche start aufruft.

Die Scene kannst du daher schon gerne in der start Methode erstellen. Für ganz kleine Projekte ist das sicher kein Problem oder für Beispiele.

Aber dennoch: Der Code wird irgendwann unlesbar und wenn du deinen Code erweitern willst, stößt du hierbei ganz stark an deine eigenen Grenzen.

Das ist ähnlich wie ein Aufsatz den du ins Heft rein geschmiert hast und später die hälfte nicht mehr lesen kannst, wenn es darum geht den weiter zu schreiben.

Die Objektorientierung ist ein gewaltiger Vorteil. Und das nicht nur in Sachen der Lesbarkeit, sondern auch wenn es um Erweiterung und Funktionalität geht.

Ob wir das 'schlimm' finden, ist eigentlich irrelevant. Du wirst es selbst irgendwann 'schlimm' finden. An dem Punkt würde ich mal an deine letzte Snake-Frage verweisen: 

Da war gegen Ende die Nachvollziehbarkeit fast gegen 0 und nachdem ich dir zu der Frage nur einen Denkanstoß gegeben habe, dürftest du selbst bemerkt haben, wie schwierig es auf einmal ist, die korrekte Stelle zu finden.

Antwort bewerten Vielen Dank für Deine Bewertung

Ist das schlimm, oder ist das theoretisch egal, wie ich code?

Grade am Anfang ja. Wenn du noch Anfänger bist, sollest du schlechte Angewohnheiten vermeiden, da die womöglich nie wieder weg gehen. 

Später - wenn du sauberen Code schreiben kannst - kommt es meiner Meinung nach ganz darauf an, für welchen Zweck du Code schreibst :

- Ein Berufsprogrammierer, der für einen Kunden entwickelt und dessen Code womöglich von vielen Programmierern verstanden, erweitert und gewartet werden muss, sollte tunlichst auf guten Stil achten

- Einem Hobby Programmierer, der in seiner Freizeit zum Spaß ne App oder so schreibt, muss sich da nicht so eisern dran festhalten, da außer ihm niemand den Code verstehen muss.

Also wenn ich privat eine App oder so schreibe (Und weis, dass nur ich den Code verstehen muss und dieser 2000 Zeilen auch nicht übersteigt), dann geh auch mal etwas schlampiger mit der Objekt Orientierung um. Für gewisse Konstanten (z.B. Bildschirmauflösung) eine "globale" Variable hernehmen oder einer Methode schreiben, die etwas länger ist als gewünscht (zB zum zeichnen von Graphiken), sind für mich verkraftbare Übertretungen.

Aber den gesamten Code in eine Klasse klatschen ist wirklich sehr schlampig. Ich bezweifele, dass du nach 2 Wochen noch weist was wo stand.

Und ja, ich bin mir bewusst, dass für dieses Statement einige nette Kommentare von anderen (Berufs)Programmierern geben wird :D.

Antwort bewerten Vielen Dank für Deine Bewertung
Kommentar von ceevee
20.07.2016, 15:43

Und ja, ich bin mir bewusst, dass für dieses Statement einige nette Kommentare von anderen (Berufs)Programmierern geben wird :D.

Ich hab keine Ahnung, welche Kommentare du erwartest.. deine Antwort ist aber in Ordnung, zumindest ich hab daran nix zu meckern. :)

0

Sobald du mal dein erstes Programm schreibst, wird sich das schnell von selbst erledigt haben. Davon abgesehen: Um beurteilen zu können, ob du in die falsche Richtung marschierst bräuchte mal wohl man ein Beispiel.

Antwort bewerten Vielen Dank für Deine Bewertung

Geh schon aber iwann kommste halt nichtmehr weiter oder deine Code wird einfach unwartbar!

Antwort bewerten Vielen Dank für Deine Bewertung

In der Main (ich mache das jedenfalls bei C# so) steht entweder

der Aufruf zum Auswerten der Kommandozeilenparameter, nach der Rückkehr der Aufruf der Usage-Ausgabe oder der Aufruf der eigentlichen Programmaktion

oder

das Erzeugen des Hauptfensters (wie vom Wizard generiert), bei GUI-Programmen fasse ich die Main nicht an.

Das mache ich auch bei wirklich winzigen Programmen so. Bei denen steht aber alles in der Program-Klasse (C# hat keinen Code außerhalb von Klassen).

Antwort bewerten Vielen Dank für Deine Bewertung

Was möchtest Du wissen?