Hallo,

was könnten denn Argumente für objektorientierte Programmierung sein?
Ständig muss ich mich rechtfertigen, warum ich in Java denn nun Objekte anlege und gegen Interfaces programmiere. Dass sowas zwar initial aufwendiger ist, aber bei späteren Änderungen Vorteile bringt, ist schwer zu vermitteln, wenn die Leute (oftmals die, die Entscheidungen treffen) nicht auch selber entwickeln.
Was gibt es also für weitere Argumente dafür?

Gruß
Gerrit

Es ist doch letztendlich so, dass das Tippen von ein paar Zeilen mehr nicht wirklich eine ernstzunehmende Zeiteinbuße darstellt, es wird in den meisten Fällen ohnehin von der IDE abgenommen. Diesem Argument könnte man auch damit entgegenen, dass man sich durch Polymorphie viel Code spart, der in anderen Sprachen notwendig wäre.

Die Vorteile von OOP zahlen sich im long-run aus, denn "OOP done right" verringert den Wartungsaufwand einer Applikation enorm, wenn man sich bereits während der Entwicklung über zukünftige Erweiterungen oder Änderungen Gedanken gemacht hat.

Schön geschriebener und strukturierter Code ist in einer OOP-Sprache auch einfacher lesbar als Codes für non-OOP-Sprachen. Dies macht sich insbesondere bei großen Projekten bemerkbar.

Ich würde die Validierung und die möglichkeit des Recycling aufgreifen. (Im Endeffekt geht es auch um Geld.)

Jede Funktion sollte Validiert werden und nach einer Änderung des Codes kann man entweder alles Validieren oder nur das Objekt das verändert wurde.
Ausserdem kann man einmal geschriebene und validierte Objekte jederzeit wieder verwenden, was bei reinen Funktionen doch öfter mal schwer ist. Somit wären Objekte jederzeit ein Zeit-Kosten-Vorteil.

OOP ist auch nur ein Werkzeug. Wenn das Projekt nicht dazu passt oder der Programmierer nicht damit umgehen kann hilft das beste Werkzeug nicht.

Insbesondere bringt es nichts, jemanden der prozedural (und nicht in Objektorientiert) denkt, mit einer Objektorientierten Sprache arbeiten zu lassen. Das Ergebnis ist dann meist richtig schlecht. Die Alteingesessenen davon zu überzeugen kann also voll nach hinten los gehen.

Bei den Projekten, die ich bisher in den Fingern hatte, gab es aber ein paar Tendenzen:

- Je größer das Projekt und je mehr dran rumfummeln, und vorallem je länger es wächst, desto größer wird der Vorteil
- OOP hilft bei der Strukturung. Das alleine ist unter bestimmten Umständen schon ein Killerargument, da es enorm Zeit und Nerven spart (und dazu noch Fehler vermeidet). Dazu gehört auch:
-- der Namensraum wird im allgemeine besser aufgeteilt (überlegt mal, eviele Funktionen namen get() du implementiert hast. Und nun überlegt mal, die müßtest allen individuelle Namen geben: getNameofInputFile(), getValueOfDateInRecordUser1(), getStringValueOfWindowTitleResultEception(), etc
-- Ich hab schonmal ne Woche nach allen Funktionen gesucht hast, die vielleicht oder auch nicht, direkt oder indirekt eine bestimmte Variable manipulieren. In OOP ist idealerweise diese Variable nur über zugehörige Methoden manipulierbar.
-- Code ist im allgemeine lesbarer, was Fehlern vorbeugt und nicht nur bei der Maintainance enorm Zeit spart.
- Codewiederverwendung durch Vererbung (spart zeit, geld, vermeidet Fehler). Bei einigen Projekten kann das ein enormer Gewinn sein (klassisches Beispiel sind GUIs)
- In C muß man vieles durch Funktionspointer und große switches "nachbauen". Das ist Fehlerträchtig (vor allem auch Copy'n'Paste fehler), unschön und braucht Zeit
- Constructoren und destruktoren helfen auch. Ob sonst jeder immer drandenkt, dass der, bevor er die struct SpecialRecord verwendet, noch InitSpecialRecord() aufrufen muss? Das gleiche mit Destruktoren. Kann enorm helfen, gerade in C/C++ sind un-/fehltinitialisierungen gerne mal ein echtes Problem.
- Oben klang schon an: Zugriffschutz (private, protected) kann ein Segen sein, vorallem wenn viele Leute dran rumfummeln.
- Statt interfaces kann man auch alle Funktionen in einer Doku festlegen, und hoffen das die auch jeder ließt und so implementiert. Kann funktionieren, oder auch nicht. Je mehr dran rumfummeln, je weniger die sich auskennen, je fauler die sind, .... desto mehr findet man da Compilerunterstützung gut. Mal ganz abgesehen davon, dass nur mit OO-Classen/Interfaces Polymorphie und Codewiederverwendung kriegt (siehe die oberen Punkte).

So, das war jetzt nur so die ersten Dinge die mir in den Kopf kamen. Hab vermutlich das wichtigste vergessen - aber vielleicht hilft es für den Anfang.

Leute die Entscheidungen treffen interessieren sich oft für eine Sache: Geld! Mit technischen Vorteilen wirst du also eher auf taube Ohren stoßen.

Deshalb pack dir einfach den Zeitvorteil und zeig ihnen, dass die Wartung eines OOP Programmes sehr viel weniger Zeit kostet und dadurch natürlich auch Kosten spart.

Das ist ein sehr schweres Thema, wie man beispielsweise an dieser Diskussion sieht:
https://www.xing.com/app/forum?op=showarticles;id=21373612

Ich programmiere auch gern objektorientiert. Aber ich habe mich auch schon in zu komplexen Modellen verrannt und damit einfach Zeit sinnlos verbraten. Ein Pro-Killerkriterium für OOP wird sich kaum aufstellen lassen.

Grundsätzlich hilft OOP, sinnvoll dosiert angewendet, den Code lesbar zu halten, weil Funktionen leichter dort angesiedelt werden, wo sie hingehören.