2018-11-09T09:37:04 rosti

D.h., OOP ist nur eine andere Art und Weise seinen CODE zu organisieren, so sehe ich das.

Es gibt aber auch Situationen, in denen OOP sinnvoll ist und dann darüber, also über die reine Code-Organisation hinausgeht.
Wenn man z.B. ein Buchhaltungsprogramm hat, und darin eine Klasse "Konto", nur mit den Attributen "Name" und "Nummer" und den Methoden "Buche Zugang", "Buche Abgang" und "Zeige Saldo", dann ist das schon ziemlich cool, denn man kann sich dann vom Code (beinahe) lösen und sich nur darauf konzentrieren, was ein Konto denn so macht. Man kann viele Konten in einem Array haben und so eine ganze Buchhaltung abbilden.
Oder sagen wir eine Person in einem Spiel mit Attributen wie "Gesundheit" (von 100 bis 0), usw. und Methoden wie "Wirf Stein" oder "Gib Stein an". Dann hat man meinetwegen mehrere solcher Personen-Objekte und ein Steinobjekt, usw. und kann dann das gewünschte Szenario relativ plastisch abbilden.
Irgendwann löst man sich dann von dem Denken in Referenzen.
Man muß auch sehen, daß das mit der "gesegneten Referenz" nur eine Krücke war, um diese Konstruktionen oben zu ermöglichen. Ziel war dabei nicht, daß es bei der Referenz bleiben sollte. Es sollte zu einem Denken in Objekten, und dem, wie sie sich verhalten, führen.

Aber ja, man kann es auch nur technisch als "package", also als Container für Variablen und Funktionen betrachten.

Bekanntlich wurde die Idee der OOP 1984 eingeführt (nachdem Steve Jobs bei Xerox (vermutlich letztlich vom US-Militär) drei Dinge gezeigt worden waren, von denen eine die OOP war).
Wenn man bis 2018 ohne das Denken in Objekten ausgekommen sein sollte, wird man es wohl auch weiterhin. ;)
Last edited: 2018-11-09 23:33:26 +0100 (CET)