Objektorientiertes Denken - Kopf sagt nein

Hallo,

ich habe ein Problem mit Objektorientierter Programmierung. Ich finde das Objektorientierte Denken kompliziert und stellenweise auch umständlich.
Mein Kopf kommt mit strukturierten Anweisungen wie man es von VHDL oder AWL kennt, viel besser zu recht. Ich habe mir schon etliche Java Tutorials reingezogen und verstehe auch den Kern und den Sinn der Objektorientierung. Bei kleinen Programmen, mag sich die Realität noch ganz gut in Objekte abstrahieren, jedoch finde ich es echt sehr schwer große Programmlogiken in Objekte zu verpacken.
Kurzum, mir wäre es viel lieber alles strukturierter zu Programmieren. Damit komme ich irgendwie besser zu recht.

Dennoch würde ich gerne besser Java können. Ich weiß leider nur nicht wie ich das Objektdenken im praktischen Sinn für größere Programme lernen soll.
Die kleinen Beispiele die es im Internet geht sind hier nicht gemeint, die verstehe ich auch. Aber bei größeren Sachen wird das echt ekelhaft wie ich finde...

VHDL zählt ja nicht wirklich, das ist ja mehr eine Beschreibungssprache als wirklich eine Programmiersprache. Und aus AWL entnehme ich, dass du aus der SPS Ecke kommst. Richtig?

Mit welchen Systemen hast du da schon gearbeitet? Denn die Systeme die ich kennen (oberflächlich Siemens, sonst ABB), sind vom Haus aus schon OO. Auch wenn du den Inhalt mit AWL füllst. Sind doch die Funktionsbausteine an sich Objekte.

Bei mir ist das eher umgekehrt. Für alles kleine nehmen ich lieber Skriptsprachen, für grösseres dann C# oder Java. Für mich resultiert das in weniger Code und weniger Arbeitsaufwand.


Wo hast du denn Schwierigenkeiten, kannst du da mal ein konkretes Beispiel zeigen?

Mich würd's freuen, wenn sich die Welt mal auf eine einheitliche Definition von "Objektorientierung" einigen könnte. Ich habe häufig den Eindruck, Objektorientierung bedeutet für jeden was anderes, und für nicht wenige scheint es so viel zu bedeuten wie "Na ja, das ist was mit Klassen und so ..."

Zwei Dinge dir mir spontan einfallen:
- Ein Objekt kann und muss die Realität nicht vollständig abbilden. Was du abbilden musst ist nur der Teil, der für dein Problem relevant ist.
- Ein Objekt muss nicht einem realen greifbaren Gegenstand entsprechen. Es kann ebenso ein abstraktes Gebilde (z. B. einen Vorgang) abbilden.

Was hilft ist das was du mit dem Programm erzeugen willst erstmal in anwendungsbezogene Sätze umzuschreibe. "Hans bestellt sich Schuhe im Online-Shop". Dann kannst du mit linguistischer Analyse ermitteln was die Klassen sein sollen "Hans", "Schuhe" und "Online-Shop" und die zugehörigen Methoden "bestellt(Schuh)" zB.

Objektoritientierung ist beispielsweise Smalltalk. Das ist 100% objektorientiert. Andere Sprachen sind nur zu einem gewissen Grad objektorientiert.

Für Deadmanshand werfe ich sonst mal den begriff Softwaretechnik in den Raum. Hier wird eingies behandelt, wie man am Besten mit größeren Softwareprojekten umgehen kann. Da gibt es dann auch Themen wie Entwurfs- und Architekturprinzipien, mit dessen Hilfe Du großen Code "gut strukturieren" kannst. Habe hier leider keine Buchempfehlung parat, aber so als kleine Empfehlung.

"Entwurfs- und Architekturprinzipien erleichtern den Umgang mit
Komplexität und führen zu besser strukturierter, leichter
verständlicherer und veränderbarer Software."

"Jedes Objekt in einem objektorientierten System sollte für eine klar
definierte Aufgabe zuständig sein."

Objektorientierte Programmierung ist nichts anderes als die Idee eine Datenstruktur und die Funktionen die von dieser Datensturktur abhängig sind (in einem Objekt) zusammenzubringen.

Mehr ist das wirklich nicht. Es gibt oft diese Diskussionen über Sinn und Unsinn von OO-Sprachen, diese beziehen aber immer irgendwelche Besonderheiten die versch. Sprachen mit sich bringen ein anstatt sich auf das wesentliche zu konzentrieren.

Daraus ergeben sich zwar weitere Konzepte wie Vererbung, Kapselung und Polymorphismus. Dass wäre dann aber wieder eine andere Diskussion.

Was die von dir genannten Technologien angeht (ich kenne sie nicht, hab bloß gegoogelt) so scheint VHDL keine Programmiersprache zu sein, sondern eine Deklarative Beschreibung einer integrierten Schaltung, was AWL angeht ist es eine Sprache zur Steuerung integrierter Schaltungen die sehr nah an der Hardware arbeitet.

Lass mich raten, bist du Mechatroniker?

Jedenfalls haben beide etwas gemeinsam, sie arbeiten auf fest vorgegebener Hardware die sich zur Laufzeit nicht ändert.
Java und andere Programmiersprachen verfolgen ganz andere Ziele. Java z.B. weiß extrem wenig davon auf welcher Hardware sie läuft und der Zustand und Umfang des ausgeführten Programms können sich schlagartig ändern. Man kann sie deshalb schlecht vergleichen.

Der nächste Punkt, große Programmlogiken in Objekte zu verpacken macht keinen Sinn, schlimmer noch, wenn man eine Funktion als groß bezeichnen kann ist sie dann wahrscheinlich viel viel größer als sie sein sollte. Hierzu kann ich dir herzlich ein Buch von Uncle Bob empfehlen: Clean Code.
Sollte jeder Programmierer auswendig kennen

Letztendlich geht es hier tatsächlich nur darum wie man mit der meist gewaltigen Menge an Code besser umgehen kann (wir sprechen hier oft von mehr als 10 Mio. Zeilen Code). Ja, du kannst auch mit AWL große und komplizierte Projekte umsetzen, die Frage ist aber wie gut so ein Programm von jemandem verstanden werden kann der es zum ersten Mal sieht, wie gut es sich erweitern und ändern lässt, wie gut sich test schreiben und automatisieren lassen, wie leicht ein Fehler gefunden kann und wie angenehm es zu lesen ist.

Nehme mir das nicht übel aber ich glaube das AWL in keinem dieser Kriterien gut abschneiden würde.

Creati schrieb:

Für Deadmanshand werfe ich sonst mal den begriff Softwaretechnik in den Raum. Hier wird eingies behandelt, wie man am Besten mit größeren Softwareprojekten umgehen kann. Da gibt es dann auch Themen wie Entwurfs- und Architekturprinzipien, mit dessen Hilfe Du großen Code "gut strukturieren" kannst. Habe hier leider keine Buchempfehlung parat, aber so als kleine Empfehlung.

Zum Vergrößern anklicken....

Buchempfehlung

Softwaretechnik umfasst zumindest so wie ich das kenne eher so ein Quatsch wie UML. (Oh wie ich UML hasse )

Ich komme aus der Automatisierungstechnik Ecke und habe täglich mit der Programmierung von SPS Steuerungen zu tun. Die Programmierung ist sehr hardwarenah (was mir besser gefällt) und strukturiert.

Manch einer mag sich Fragen warum ich überhaupt Java können will. Der Hintergrund ist, dass ich an einer eigenen (einfachen) App arbeite. Aber ich habe momentan noch Schwierigkeiten.

Bei Java habe ich oft das Problem, das ich die zig Methoden nicht kenne. Klar gibt es die API wo man nachschauen kann. Aber hier ist es eher so, das man in die API schaut wenn man sich über die Funktion einer Methode im unklaren ist. Aber nicht explizit nach einer Funktion sucht, die man eigentlich benötigt.
Wäre nicht das erste mal, dass ich was programmiere und später feststelle, das es hierfür auch schon eine fertige Methode gibt...

Desweiteren finde ich es ziemlich komplex wenn Dinge wie Polymorphie und Verberung hinzu kommen. Ich frage mich oft, an welcher Stelle ein Objekt überall benötigt wird oder wo es aktuell bearbeitet wird. Ich finde das wird schnell unübersichtlich. Aber das mag auch sicher an meiner Kraut und Rüben Softwarearchitektur liegen.

Am übersichtlichsten finde ich es übrigens, wenn alles in einer Klasse ist ( bei kleineren Programmen). Bei großen keine Frage, aber bei kleinen Sachen hau ich gern mal alles in eine Klasse, weil mir das rumgekacke mit zig kleinen Klassen und Objektaufrufen zu streßig ist.
Ich weiß, dass viele hier nun Bauchschmerzen bekommen

Deadmanshand schrieb:

Bei Java habe ich oft das Problem, das ich die zig Methoden nicht kenne.

Zum Vergrößern anklicken....

Es ist fast immer so dass man nicht alle Methoden kennt, es sind schlicht und einfach zu viele. Das stellt aber überhaupt kein Problem da weil ein Java Programmierer eine richtige IDE verwendet und keinen Siemens Quatsch
Das sieht dann so aus:



Ich muss nicht wissen welche Methoden mein Objekt bietet meine IDE zeigt es mir, zusammen mit den Parametern die sie entgegennehmen, dem Rückgabetyp, der Dokumentation und der Klasse aus der die Methode ursprünglich stammte.
Ohne gute Code Completion wäre ich längst in einer geschlossenen Anstalt

Deadmanshand schrieb:

Desweiteren finde ich es ziemlich komplex wenn Dinge wie Polymorphie und Verberung hinzu kommen.

Zum Vergrößern anklicken....

Wenn man sich an diese Konzepte erst einmal gewöhnt hat sind diese wirklich trivial. Wenn du etwas kompliziertes haben willst dann lerne Haskell.

Deadmanshand schrieb:

Aber das mag auch sicher an meiner Kraut und Rüben Softwarearchitektur liegen.

Zum Vergrößern anklicken....

Ich kenne ein paar Leute die sich mit SPS rumschlagen müssen, der Kraut und Rüben Ansatz scheint sich soweit ich sagen kann in der Industrie gut bewährt zu haben.

Deadmanshand schrieb:

Am übersichtlichsten finde ich es übrigens, wenn alles in einer Klasse ist ( bei kleineren Programmen). Bei großen keine Frage, aber bei kleinen Sachen hau ich gern mal alles in eine Klasse, weil mir das rumgekacke mit zig kleinen Klassen und Objektaufrufen zu streßig ist.
Ich weiß, dass viele hier nun Bauchschmerzen bekommen

Zum Vergrößern anklicken....

Überhaupt nicht, JAVA ist dafür auch nicht sonderlich gut geeignet. Das was du allerdings als kleinere Programme bezeichnest sind für mich Skripte, und für diese gibt es entsprechende Skriptsprachen.

Ich kann dir hier Scala empfehlen, eine sehr mächtige Sprache die sozusagen entstanden ist weil die Entwicklung mit Java den Leuten zu lästig geworden ist. Scala vereint perfekt funktionale Programmierung mit den Ansätzen der Objektorientierten Programmierung und lässt dem programmieren alle Freiheten (auch die Freiheit Schei*e zu bauen). Darüber hinaus bietet sie Unterstützung für Skripte und ein REPL/Worksheets die für solche kleinen Lernaufgaben perfekt geeignet sind.
(Es gibt hierzu auch extrem gute kostenlose Kurse bei Coursera.org)

Vielleicht solltest du mal Clean Code lesen. Das könnte dir helfen zu verstehen, wozu Klassen am besten verwendet werden. Mit dem typischen "Auto besteht aus 4 Rädern und kann fahren"-Beispiel hat das nicht viel zu tun.

Letztendlich dienen sie entweder der Zusammenfassung/Kapselung mehrerer Daten (= Datenstruktur) oder als Zusammenfassung von Funktionen (Methoden). Beides zu vermischen sollte vermieden werden.

Wenn jede Funktion nur aus wenigen Zeilen Code besteht (ca. 5) und max. 2 Parameter hat, muss man seinen Code zwangsläufig in mehrere Klassen aufteilen, die jeweils nur eine Sache machen (mithilfe von eben diesen Funktionen). Sonst nimmt die Anzahl der Funktionen einfach überhand. Und schon ergibt das mit den Klassen Sinn.

Jetzt sind es schon 2 die dir Clean Code empfohlen haben
Lese es!

pmkrefeld schrieb:

Jetzt sind es schon 2 die dir Clean Code empfohlen haben
Lese es!

Zum Vergrößern anklicken....

Habe eben mal auf amazon nach dem Buch geschaut. 40€ sind natürlich schon eine Hausnummer...

Ich kenne Java nicht, aber wenn du Objektorientierte Programmierung mal verstanden und eingesetzt hast, wirst du es lieben.

pmkrefeld schrieb:

Jetzt sind es schon 2 die dir Clean Code empfohlen haben
Lese es!

Zum Vergrößern anklicken....

Ich reihe mich mal ein. Wenn bei uns jemand neu anfängt, dann knallen wir ihm (halb-symbolisch) das Buch auf'n Tisch. Pflichtlektüre meines Erachtens.

Deadmanshand schrieb:

Habe eben mal auf amazon nach dem Buch geschaut. 40€ sind natürlich schon eine Hausnummer...

Zum Vergrößern anklicken....

Es war auch ne Hausnummer das Buch zu schreiben

Die Kindle-Version kostet übrigens 25 Euro und das ist schon sehr human.

Mir ging es anfangs auch so. Wenn Du aber mal in einem realen, größeren Softwareprojekt gearbeitet hat, werden die Vorteile schnell klar und irgendwann denkst Du auch gar nicht mehr anders. Aber klar, wenn man Jahre lang das Andere gewöhnt ist, ist es schwer sich umzugewöhnen.

Wenn man OO konsequent anwendet, vermeidet man quasi automatisch Spaghetti Code, jede Klasse bildet nur einen Teil des gesamten Gebilde ab und kann nur das was dieser Teil auch können soll. Damit wird es insgesamt viel überschaubarer und händelbarer, gerade je größer und komplexer das Projekt wird.

Natürlich kann man auch in einer Objektorientierten Sprache Spaghetti Code schreiben, es ist aber einfacher zu vermeiden.

pmkrefeld schrieb:

Buchempfehlung

Softwaretechnik umfasst zumindest so wie ich das kenne eher so ein Quatsch wie UML. (Oh wie ich UML hasse )

Zum Vergrößern anklicken....

Softwaretechnik hatte ich soweit an der Uni. Dort haben wir im ersten Semester Prozessmodelle gemacht (Scrum, etc.) und im 2. Semester UML, Architekturvertiefung, Entwurfs- und Architekturprinzipien sowie Entwurfs- und Architekturmuster. Es beinhaltet also mehrere Aspekete. UML bildet nur einen kleinen Teil ab.

Creati schrieb:

Softwaretechnik hatte ich soweit an der Uni. Dort haben wir im ersten Semester Prozessmodelle gemacht (Scrum, etc.) und im 2. Semester UML, Architekturvertiefung, Entwurfs- und Architekturprinzipien sowie Entwurfs- und Architekturmuster. Es beinhaltet also mehrere Aspekete. UML bildet nur einen kleinen Teil ab.

Zum Vergrößern anklicken....

In meinem Fall war es nur 1 Semester, eine der sinnlosesten Vorlesungen überhaupt, wie gesagt eig nur UML, dafür aber über 1200 Vorlesungsfolien

@pmkrefeld: ...wenn alle nur noch Mathematik, theoretische Informatik / Algorithmik, o.Ä. belegen würden, hätte man aber zum Einen zu wenig Softwareingenieure für die Wirtschaft und zum Anderen kaum noch Absolventen - da würden um Größenordnungen weniger Leute das Studium schaffen.
Wobei ich es an Universitäten auch eher unpassend finde; diese recht praktischen Auswendiglernvorlesungen könnten imho ruhig komplett an FHs oder Bildungsinstitute mit dualen Studiengängen wandern.