| 

.NET C# Java Javascript Exception

0
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
News:
07.09.2009
gerrit 1 2 2
6 Antworten
1
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.
07.09.2009
TheFalcon 121 1 1
1
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.
07.09.2009
ralf 61 1 2
1
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.
07.09.2009
uvatter 71 1 1
Sehr guter Beitrag, muss ich sagen. Mehr Argumente wären mir auch nicht eingefallen ;)
darkdust 07.09.2009
0
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.
07.09.2009
Feroc 1,2k 2 9
0
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.
07.09.2009
noi76 41 1 1
0
Mit OOP ist man näher an der Realität und damit näher an den Anforderungen des Kunden. Klassen sind keine Alibi-Konstrukte sondern Abbildungen realer oder virtueller Sachverhalte. Es kann schneller fachlich richtig entwickelt werden.

Ansonsten schließe ich mich den vorherigen Autoren an, dass die Verwednung von OOP interessanter wird, je größer das Projekt angelegt ist. Die Quellcode-Massen sind nur noch mit einer einhergehenden Granularität zu handhaben.
09.02.2011
oopexpert 455 1 8

Stelle deine Java-Frage jetzt!