Wie kann ich mein 8 Klassen Gebilde objektorientierter schreiben?

[Neumi5694]

Ich halte es für kaum machbar, ein Programm ohne IDE zu entwickeln. Ich finde, dass man gerade Laufzeitfehler nicht findet, ohne Debugger. Damit kann ich Breakpoints setzen, Variablen auslesen, und den Code schrittweise ablaufen lassen. Auch wenn ich Code von anderen sehe, hilft mir das, den zu verstehen.
Ich nutze selbst Geany als IDE für Python auf dem RaspberryPI, obwohl es da "nur" die Dateiverwaltung und die Verwaltung der Erstellung gibt.

Ich würde dem TE vorschlagen, dass er man "einfache Anfängerprogramme" wie eine Adressverwaltung mit einer CRUD-Funktionalität erstellt, oder mal selbst eine Roulette-Anwendung, oder nur ein Kniffel-Spiel.

Wenn ich denke, was ich an Geld und Zeit investiert habe, um OOP zu verstehen, gerade vor dem Zeitalter des Internets, dann kann ich @KonradN mitfühlen, auch wenn ich es nicht so drastisch ausdrücken würde.

Ich werd mich mit keinem Wort gegen IDEs aussprechen
Ich mein nur, dass man für was WIRKLICH simples auch mit Notepad arbeiten kann.
Aber spätestens wenn man anfängt, mit Packages zu arbeiten (was man ab Tag 2 sollte), dann lernt man die Vorteile einer IDE und des Project-Trees zu schätzen, die ganzen nützlichen Tools wie den Debugger brauch ich gar nicht erst zu erwähnen.

Ich entwickle natürlich selbst auch auf einer IDE, auf den Build- und Test-Servern ist aber naturgemäß keine zu finden.

 

[White_Fox]

Also ich weiß nicht, je länger ich so grundsätzlich über das Ganze nachdenke umso mehr denke ich dass ich für das OOP Kram schlicht zu blöd bin :-/

Nein, das ist der ganz normale Lernprozess. Ich kann dir nur den Rat von temi nochmal ans Herz legen: Schau dir mal das Buch Entwurfsmuster von Kopf bis Fuß an. Das macht sogar Spaß zu lesen.
Und ganz ehrlich: Vergiß Lernvideos. Videos sind zum Lernen einfach Schrott.

Du kannst mit Videos zwar Dinge auf eine sehr anschauliche Art darstellen, wirklich sinnvoll ist das aber nur bei relativ überschaubaren Dingen. Komplexere Dinge erfordern es einfach, daß man darüber nachdenkt. Du mußt diese Dinge wirklich im Gehirn umherwälzen, dir z.B. Fragen dazu überlegen. Was wäre, wenn man das so macht anstatt so...und auf solche Fragen dann Antworten finden.

Beim Lesen eines Buches ist es kein Problem, kurz anzuhalten und den letzten Satz mal sacken zu lassen. Beim Videogucken kippst du dir in relativ kurzer Zeit viel Information rein, aber:

• Es findet währenddessen kaum Verarbeitung statt, weil alles einfach fertig ist.
• Es kann auch keine Verarbeitung, kein Denken währenddessen, stattfinden, wenn du es wolltest. Beim Lesen kurz anzuhalten ist tatsächlich nochmal was ganz anderes als ein Video zu stoppen.

Ich versuche es mal mit einem Beispiel:
Wenn du einen Film siehst, nimmst du relativ viel Information auf: Du siehst und hörst die Szene, wie sie ist. Dafür verbleibt kaum Interpretationsspielraum, da alles einfach vorgegeben ist.

Wenn du dagegen ein Buch liest, kommt relativ wenig Information in deinem Kopf an: Akustisch läuft bestenfalls gar nix, schlimmstenfalls versuchst du, Umgebungsgeräusche zu ignorieren. Auch visuell bleibt es relativ ruhig, viel weiß mit etwas schwarz dazwischen.
Dafür leistet dein Gehirn dabei ernsthaft Arbeit: Du liest, wie auf einer halben Seite z.B. die Umgebung beschrieben wird. Und dein Gehirn bastelt aus diesen relativ spärlichen Informationen eine Vorstellung zusammen.
Denke dir mal den umgekehrten Weg: Halte mal einen x-beliebigen Spielfilm an, und überleg dir mal wie umfangreich eine detailgetreue mündliche Beschreibung nur dieses Bildes wäre. Und ob sie je vollständig sein könnte. Anders herum entstehen solche detaillierten Bilder in deinem Kopf, aus Text aus drei oder vier Sätzen. (Oder sollten es zumindest.)

Bei uns im Studium waren die, die immer erstmal nach Lernvideos gesucht haben in der Regel auch die, die mit dem Verständnis große Probleme hatten. Sie wußten hinterher meistens einiges, meistens hat es sogar für eine gute Note gereicht. Aber verstanden haben sie meist wenig oder gar nichts. Das hat man immer dann gemerkt wenn eine Frage aufkam, die sie so noch nicht kannten. Wissen wiederzugeben ist das eine, es aber kreativ auf ein neues, unbekanntes Problem anzuwenden etwas völlig anderes.
Und wenn du Programmieren willst, wirst du letzteres weitaus öfter brauchen.

 

[berndoa]

Ich werd mich mit keinem Wort gegen IDEs aussprechen
Ich mein nur, dass man für was WIRKLICH simples auch mit Notepad arbeiten kann.
Aber spätestens wenn man anfängt, mit Packages zu arbeiten (was man ab Tag 2 sollte), dann lernt man die Vorteile einer IDE und des Project-Trees zu schätzen, die ganzen nützlichen Tools wie den Debugger brauch ich gar nicht erst zu erwähnen.

Ich entwickle natürlich selbst auch auf einer IDE, auf den Build- und Test-Servern ist aber naturgemäß keine zu finden.

oh, packages...
Da sage ich lieber erst gar nix zu.

Bisher nur zum Compilerfehler erzeugen zu gebrauchen und dass sies und jenes nicht gefunden wird, weil nicht in jenem Package oder Ordner oder der Compiler auch so zu blöd ist, ne Datei zu finden die sprichwörltich im gleichen ordner ist.

Den Quark muss ich mir auch mal noch antun -.-

Ich hasse dieses blöde Praktikum jetzt schon, so viel Mist in den man sich da einlesen und einarbeiten muss.
Also tut es das Standardpackage nicht genauso Normalsterblicher packt eh in einen Ordner was in einen Ordner gehört.
Classpath muss ja eh geändert werden sosnt findet er .jar Dateien nicht :-/

 

[berndoa]

Den Code sparst du nicht beim Implementieren von Interfaces, sondern beim Verwenden der implementierenden Klasse. Und um's Code sparen geht's auch gar nicht. Lies dir meine Beispiele oben nochmal durch. Wie sollte denn ein Mouselistener ohne Interface umsetzbar sein?

Hör endlich mal auf dich querzustellen und probier die Tips einfach mal aus ... oder hör auf Fragen zu stellen, wenn du die Antworten eh nicht annimmst.

Bingo!
Die Klasse bringt was und nciht das Interface.
Ob wir nun in der Klasse ein "implements blabla" drinsteht oder nicht, praktisch tut sie haargenau Dasselbe.

Wenns nicht ums Code sparen, geht, worum dann?

Effizienz, schnellere Codeumsetzung, weniger Speichernutzen, weniger Code Redundanz?
Methoden gibts dmait man nicht 20 mal senselben 8oder ähnlichen) Code shcreiben muss, da spart man sich was ein.

Interfaces?
Gut zu wissen dass Hund, katze Maus alles Tiere sind.
Und Alle laufen können.

Gut, man kann überall wo in ner Methodensignatur das interface als parameter vorkommt, halt ein Hund, Katze oder Maus Objekt nach Gutdünken einsetzen, kann praktisch sein.

 

[berndoa]

Am Ende des Tages ist nur eine Sache relevant: "Entweder du kennst Techologie/Methode/Technik/Framework/Tool XYZ, oder du kennst XYZ nicht."
Du kannst dich jetzt fragen, welche Antwort auf diese Frage die bessere ist.
Das einzige, was festgefahrene Meinungen, Gefühle, Befürchtungen und Vorurteile tun, ist, dich am Lernen zu hindern.
Also: Sei immer offen für alles.

Offen für Alles ist gut.

Weißt du, wie man vermutlöich offen sichtlich sieht, kriege ich es shcon nicht hin, das Geplante hinreichend gut zu programmieren.
bzw. "objektorientiert" zu programmieren (klingt für mich mittlerweile so esoterisch wie das jüngste gericht, jeder quatscht davon, aber keiner weiß so recht zu definieren was es ist und wie man schritt 1. 2. 3. mässig erreicht, dubioser Kram)

Da will ich doch nicht auch noch zusätzlich zu Java mir auch noch die IDE Sprache und Benutzung lernen (Ich mache bspw. intellij auf, bin von der Farbwahl mal shcon nicht begeistert (ich mag "white mode" wie in notepad++ und hübsches syntaxmarkieren)
, sehe dann links irgendwie .idea,.xml,.gitignore, etc. oben paar menüs un frage mich "was ist das Alles für ein Kram? und wo baue ich mir mein stinknormales java und class file? "f this shit" und machs wieder zu.
Debugger hört sich nice an, was man so liest, will ich mich aber dafür auch noch mit ide rumärgern?

Dann auch noch maven lernen weil laut google hat man ja maven, eclipse und whatnot drauf und muss die erst mal noch einstellen.

dann noch versionsverwaltungsmist, weil das praktikum es so will.

Kann ich gleich noch 5 programme dazu lernen, als wäre ich schon ein java profi und will mir noch 5 andere sachen zum gleichzeitig lernen aufbinden, von denen ich bei mind. 4 wenig nutzen sehe, ausser dass es unimässig aufgezwungen wird.

die letzten x jahre tat es schon notepad++ und konsole.

 

[yfons123]

alles was du beschreibst ist das was andere sprachen die nicht objekt orientiert sind lösen auf eine andere art und weise

 

[Meniskusschaden]

Offen für Alles ist gut.

Weißt du, wie man vermutlöich offen sichtlich sieht, kriege ich es shcon nicht hin, das Geplante hinreichend gut zu programmieren.
bzw. "objektorientiert" zu programmieren (klingt für mich mittlerweile so esoterisch wie das jüngste gericht, jeder quatscht davon, aber keiner weiß so recht zu definieren was es ist und wie man schritt 1. 2. 3. mässig erreicht, dubioser Kram)

Da will ich doch nicht auch noch zusätzlich zu Java mir auch noch die IDE Sprache und Benutzung lernen (Ich mache bspw. intellij auf, bin von der Farbwahl mal shcon nicht begeistert (ich mag "white mode" wie in notepad++ und hübsches syntaxmarkieren)
, sehe dann links irgendwie .idea,.xml,.gitignore, etc. oben paar menüs un frage mich "was ist das Alles für ein Kram? und wo baue ich mir mein stinknormales java und class file? "f this shit" und machs wieder zu.
Debugger hört sich nice an, was man so liest, will ich mich aber dafür auch noch mit ide rumärgern?

Dann auch noch maven lernen weil laut google hat man ja maven, eclipse und whatnot drauf und muss die erst mal noch einstellen.

dann noch versionsverwaltungsmist, weil das praktikum es so will.

Kann ich gleich noch 5 programme dazu lernen, als wäre ich schon ein java profi und will mir noch 5 andere sachen zum gleichzeitig lernen aufbinden, von denen ich bei mind. 4 wenig nutzen sehe, ausser dass es unimässig aufgezwungen wird.

die letzten x jahre tat es schon notepad++ und konsole.

Okay, du hast jetzt mehrfach und inzwischen auch ziemlich plausibel dargelegt, dass du die Leistungsansprüche deiner Uni nicht erfüllen kannst. Welche Konsequenz willst du denn nun daraus ziehen?

 

[mihe7]

Bei Implementieren von interfaces hat man sich keine einzige Zeile Code erspart, shcrieben muss man die ganzen Attribute und MEthoden doch genauso wie ohne Implementieren.

Nein, ein Interface hat keine Attribute. Ein Interface dient auch nicht dazu, Code zu sparen, den Sinn habe ich in #85 schon erklärt. Kurz: Du drehst mit einem Interface Abhängigkeiten um.

Ich hasse nur IDEs, Mavens und anderen unnötigen Müll, ohne den ein Programm genauso gut läuft.

Auch dazu habe ich schon einmal geschrieben, dass das doch Dir überlassen bleibt. Keiner hier zwingt Dich, irgendwas zu verwenden (in der Uni, beim Arbeitgeber sieht das anders aus). Umgekehrt kannst Du aber nicht erwarten, dass Du Lösungen auf Basis von javac, Texteditor und Batchdateien erhältst; weder hier noch sonst irgendwo im Netz.

Was die Farben betrifft: das ist doch Geschmackssache und die Editoren bieten doch die Möglichkeit, den Spaß nach den eigenen Wünschen anzupassen. NetBeans startet z. B. mit einem hellen Theme, kann aber auf ein dunkles umgestellt werden (unter https://netbeans.apache.org/download/nb120/FlatLaf-11.3.png ein Vergleich) und bei IntelliJ dürfte es halt umgekehrt sein.

Apropos Geschmackssache: was ich z. B. überhaupt nicht leiden kann, wenn die IDE im Code Parameternamen anzeigt, die nicht zum Code gehören (parameter hints). Das wirkt für mich dermaßen störend und leider haben sie das auch in NetBeans eingeführt, jetzt muss ich das immer erst abschalten oder ich gewöhne mich dran...

Und, wie auch schon mal geschrieben: wenn ich mal eben was ausprobieren will, starte ich nicht erst eine IDE. Da rufe ich jshell auf. Wenn ich fünf Java-Dateien kompilieren will, dann haue ich die in einen Texteditor und mach mal eben javac *.java. Das ist alles kein Problem, wobei die Code-Vervollständigung schon abgeht. Aber ein Projekt würde ich nie wieder ohne IDE oder ein Buildsystem machen wollen, die Zeiten sind vorbei, und Maven ist wirklich unkompliziert, wenn man keine besonderen Ansprüche stellt.

sehe dann links irgendwie .idea,.xml,.gitignore,

Das ist ganz einfach dem Umstand geschuldet, dass Java selbst (genauso wie z. B. C) nur einen Compiler mitbringt. Ein Projekt braucht aber wesentlich mehr Infos. Diese müssen irgendwo gespeichert werden. Du baust Dir z. B. eine Batch-Datei, die diese Infos enthält, die IDE speichert den Spaß halt auch irgendwo.

Dann auch noch maven lernen weil laut google hat man ja maven, eclipse und whatnot drauf und muss die erst mal noch einstellen.

Auch hier wiederhole ich mich: Du musst in der Regel gar nichts einstellen. Die POM erzeugt Dir die IDE und das wars. Wenn Du nichts besonderes willst, musst Du bei Maven auch nicht großartig etwas lernen.

Wenn es für Dich ein Problem darstellt, dass Du was lernen musst, dann solltest Du Dir vielleicht wirklich was anderes suchen. Der ganze Job besteht darin, ständig was neues lernen zu müssen: neue Technologien, neue Sprachen, neue Sprachfeatures, neue Tools, neue Betriebssysteme, neue Kunden, neue Projekte, neue Anforderungen... Das ist nicht jedermanns Sache.

die letzten x jahre tat es schon notepad++ und konsole.

Ja, eine Zeit lang taten es auch DOS und der 9-Nadel-Drucker.

 

[temi]

Blöder Bagger! So viele Hebel und keine Ahnung, wie man damit umgeht. Mit der Schaufel bin ich bisher total gut zurecht gekommen.

 

[Neumi5694]

...

Alles, was du da beschreibst, ist letztendlich doch nur, dass du dich den Prinzipien der strukturierter Entwicklung komplett verweigerst.
Für dich wäre eine Scriptsprache mit Spaghetticode geeigneter.
Verweigerst du auf deiner Festplatte auch Unterverzeichnisse? Hast du alles im Root liegen? Ich mein ... wie soll man was finden, wenn alles so verschachtelt ist?

Worum's bei Interfaces geht, haben wir dir jetzt schon zig mal gesagt. Code sparen ist so ziemlich das nutzloseste, was man sich vorstellen kann, das bringt keinem was, das Programm läuft mit viel Code genauso gut oder schlecht wie mit wenig. Wo man mit Interfaces aber doch Code 'spart' (bzw. nicht benötigt), wurde schon beschrieben (liest du die Antworten denn wenigstens?) Es geht nicht um die Klasse, sondern um diejenigen, die damit arbeiten wollen (oder in deinem Fall 'müssen'). Was "implements" bringt: Dass du die Klasse dort verwenden kannst, wo genau das erwartet wird. Wenn ein MouseListener erwartet wird, dann muss deine Klasse auch ein MouseListener sein. Hat sie die selben Methoden ist aber nicht als solcher gekennzeichnet, kann sie nicht verwendet werden. Die Runtime-Umgebung kennt den Code deiner Klasse ja nicht, die for-each Methode kennt den Code der Liste oder Collection auch nicht. Sie weiß nur, dass damit for-each möglich ist.

Ich glaube mit einem hast du Recht. Falls du uns hier nicht nur alle verarschen wird, fehlt es dir vielleicht doch am intellektuellen Zugang. VIelleicht wäre eine nicht akademische Laufbahn für dich sinnvoller. Noch hast du Zeit.
Als Jungspund hat man das Bedürfnis, alles besser zu machen als alle vorher. Aber stell dir vor: Das, was du sagst, HABEN die anderen vor dir bereits gemacht - vor 50 Jahren. Und sie haben es sein lassen, haben eingesehen, dass es Grütze war. Wenn du irgendwas besser machen willst, dann akzeptier erst mal, warum der Status Quo der Status Quo ist.


'"f this shit" und machs wieder zu'
Und deshalb lernst du nichts.
Dabei musst du dir die xmls noch nicht mal anschauen, sie beschreiben nur das, was beim Kompilieren, Packen und Deploy passieren soll. Du kannst das alles auch manuell oder per Batch erledigen, ist halt unnötiger Aufwand. Angenehmer ist, einfach Ctrl+F5 zu drücken, um das Debuggen des Programms zu starten.

 

[mihe7]

bzw. "objektorientiert" zu programmieren (klingt für mich mittlerweile so esoterisch wie das jüngste gericht, jeder quatscht davon, aber keiner weiß so recht zu definieren was es ist und wie man schritt 1. 2. 3. mässig erreicht, dubioser Kram)

OO ist kein Rezept oder Algorithmus, sonder ein Paradigma. Dementsprechend findet die Diskussion auch auf einer solchen Ebene statt. Die prozedurale Programmierung zerlegt Probleme in Datenstrukturen einerseits und Prozeduren, die mit den Strukturen arbeiten, andererseits. Die objektorientierte Programmierung zerlegt Probleme in Objekte, die über Nachrichten untereinander kommunizieren. Weder das eine noch die andere Beschreibung erklären irgendwelche Schritte, mit denen Du ein Problem löst.

Dr. Alan Kay, der den Begriff eingeführt hat, meint dazu: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

Und das ist es auch schon. Dinge, wie Vererbung oder Klassen tauchen da nicht auf. Die Grundidee waren übrigens biologische Zellen oder Computer in einem Netzwerk, die nur in der Lage sind, über Nachrichten miteinander kommunizieren.

Für die Kommunikation reicht es natürlich nicht, willkürlich irgendwelche Nachrichten auszutauschen. Empfänger und Sender müssen sich mindestens darüber einig sein, wie die Nachricht auszusehen hat und was sie bedeutet.

Nun könnte man hergehen und einen Webserver bauen und für den Desktop ein Anzeigeprogramm dazu. Dann gibt es einen Apache, der "Apache spricht" und einen nginx, der "nginx spricht" usw. Dementsprechend gäbe es die passenden Anzeigeprogramme dazu: den Apache-Browser für Apache-Server und den nginx-Browser für nginx-Seiten.

Das hört sich konstruiert an, ist aber z. B. bei Messenger-Anwendungen absolut üblich: für Whatsapp brauchst Du Whatsapp-App, für Threema die Threema-App, für Signal die Signal-App usw.

Also, was tun? Man definiert ein Protokoll: HTTP. Der Browser kann nun entwickelt werden, ohne den Server kennen zu müssen und umgekehrt kann der Server entwickelt werden, ohne zu wissen, welcher Browser eingesetzt wird. Problem gelöst.

Da Java über ein statisches Typsystem verfügt, muss man das Protokoll explizit definieren. Nichts anderes macht man in Java mit einem Interface.

In Sprachen ohne statischem Typsystem (z. B. JavaScript) brauchst Du weder Klassen noch Interfaces, da die Bindung sowieso erst zur Laufzeit erfolgt. Da kann ich z. B schreiben:

function x(e) {
    e.doSomething();
}

In Zeile 2 wird doSomething() auf e aufgerufen. Was e ist? Keine Ahnung. Irgendein Objekt, das die Methode doSomething() anbietet. In Java funktioniert das so nicht, weil der Typ von e angegeben werden muss und der Typ die verfügbaren Methoden definiert. Da man aber keine Abhängigkeit zu einer bestimmten Implementierung (im Beispiel oben Apache, nginx) haben will, kann man einfach ein Interface verwenden:

interface Doable {
    void doSomething();
}

// und irgendwo die Methode
public void x(Doable e) {
    e.doSomething();
}

 

[Neumi5694]

In Sprachen ohne statischem Typsystem (z. B. JavaScript) brauchst Du weder Klassen noch Interfaces, da die Bindung sowieso erst zur Laufzeit erfolgt. Da kann ich z. B schreiben:

function x(e) {
    e.doSomething();
}

In Zeile 2 wird doSomething() auf e aufgerufen. Was e ist? Keine Ahnung. Irgendein Objekt, das die Methode doSomething() anbietet. In Java funktioniert das so nicht, weil der Typ von e angegeben werden muss und der Typ die verfügbaren Methoden definiert. Da man aber keine Abhängigkeit zu einer bestimmten Implementierung (im Beispiel oben Apache, nginx) haben will, kann man einfach ein Interface verwenden:

interface Doable {
    void doSomething();
}

// und irgendwo die Methode
public void x(Doable e) {
    e.doSomething();
}

@berndoa
Auf das Argument: "Aber das geht mit einer abstrakten Klasse doch auch" ist die Antwort: "Vollkommen richtig".
Und jetzt nehmen wir noch eine zweite Methode, die ein Interface des Typs "AnotherInterface" erwartet.
Kannst du eine Instanz deiner Klasse übergeben, wenn sie doch von AbstractDoable ableitet? Nur, wenn du noch "implements AnotherInterface" dazuschreibst. Dann nämlich hat sie alle notwendigen Methoden von Doable UND AnotherInterface, ist vielseitiger.

 

[yfons123]

Als Jungspund hat man das Bedürfnis, alles besser zu machen als alle vorher.

naja wenn man den ansatz verfolgt: ich muss es unbedingt shclechter machen als vorher

ist das eher kontraproduktiv nehm ich mal an

 

[temi]

@berndoa du musst dich jetzt mal entscheiden, was du machen möchtetst.

Du kannst dich mit der Thematik beschäftigen und Fragen stellen, wenn dir etwas unklar ist oder du machst weiter wie bisher und lamentierst hier herum, wie unnötig, bla bla bla und unsinnig OO, IDEs und was noch alles doch sind.

Zweiteres wird dir allerdings nicht helfen und uns wirst du nicht von deiner Meinung überzeugen. Damit verschwendest du nur deine Zeit.

Und ja, ich bin inkonsequent, denn ich wollte eigentlich nicht mehr antworten und das werde ich jetzt auch tun, sofern du dich nicht für die erste Möglichkeit entscheidest.

 

[Neumi5694]

naja wenn man den ansatz verfolgt: ich muss es unbedingt shclechter machen als vorher

ist das eher kontraproduktiv nehm ich mal an

Das steht dann im nächsten Teil des Posts, den du nicht zitiert hast.