Hi!

Ich weiß nicht ob ich hier in der richtigen Rubrik bin, aber ich habe irgendwie nichts besseres gefunden:

Wenn man die Wahl zwischen Objektorientiertem- und Strukturiertem Softwaredesign hat, wie kann man argumentieren, dass man sich für das OOD entschieden hat? Was spricht dafür?

Objektorientiertem- und Strukturiertem Softwaredesign

Das eine schließt das andere nicht unbedingt aus. Zwar rechnet man structured programming klassischer Weise dem prozeduralen Paradigma zu; doch im weitesten Sinne kann man davon sprechden, dass OOP eine Weiterentwicklung darstellt. Die Kontrollstrukturen existieren auch im OOP-Paradigma, die klassische Sequenz findet sich bei OOP e.g. als method chaining, template pattern oder ähnlichem wieder. Typischerweise spricht man nicht mehr von Subroutinen, sondern von Methodenaufrufen. Iterationen existieren in der erweiterten Form von forEach(...) und dem Iterator-Konzept weiter. Beide haben das Ziel durch Modularisierung den code reuse zu erhöhen. Der Vorteil durch OOP besteht nun darin, dass man komponenten basiert entwickeln kann, i.e. durch das Prinzip der Datenkapselung: Daten und Funktionen die diese Daten manipulieren werden in einem sauberen OOD zusammen gefasst (http://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs#SOLID-Prinzipien ). Somit können komplexe Softwareprojekte nicht nur in beliebig viele Teilprobleme zerlegt, und entsprechend an beliebig viele Teams delegiert werden, sondern man hat sogar den Vorteil, dass die Funktionalität eine Objekts durch ein fest definiertes API genutzt werden kann. Dabei ist die tatsächliche Implementierung unabhängig vom Gebrauch. Ein großer Vorteil wurde zum Zeitpunkt der Entwicklung von OO-Sprachen in der sog. Vererbung gesehen. Aus historischer Sicht macht es nur bedingt Sinn, ganze Klassenbäume aufzumalen. Was in der Praxis genutzt wird, ist die sog. Interface-Vererbung / Traits in Scala. Im Grunde geht es darum, dass Klassesvererbung eine Reihe von ähnlichen Objekten beschreibt, während Interfacecererbung lediglich ein API beschreibt an welches sich implmentierende Klassen halten müssen. Alle Implementierung findet an der implementierenden Klasse selbst statt, somit hat man zwei Vorteile a) Überblick und http://devipb.fachinformatiker.de/uploads/emoticons/default_cool.png' alt='B)'> Flexibilität. Entsprechend baut man Klassen aus einzelnen Komponenten auf, die entsprechendes Verhalten mitbingen. Das dahinter stehende Prinzip lautet Bevorzuge Komposition statt Vererbung. )

Das dritte Verkaufsargument für OOP ist die sog. Polymorphie, was es erlaubt, verschiedenartige Komponenten auf gleiche Weise anzusprechen. Wichtig ist hier eben das API(Sonderfall: Duck-Typing in dynamisch typisierten Sprachen).

Ein gemeinsamer Nachteil beider Programmierparadigmen ist die Behandlung von Zustandsinformationen (State: https://youtu.be/7Zlp9rKHGD4?t=4m8s). Das Problem ist implizit durch das funktionale Paradigma gelöst, da es dort Zustandsinformation existiert. Man hat lediglich Input für Funktionen und entsprechenden Output. Zwar kann man sich in verschiedenen Programmiersprachen funktionaler Prinzipien bedienen, teilweise sogar mit sog. immutable collections behelfen. Aber das kann zu Laufzeitschwierigkeiten führen, wenn der Garbage Collector nicht mit dem Aufräumen hinter her kommt.

Zusammenfassend kann man sagen: OOP ist strukturierte Programmierung on steroids.

Das geht natürlich schon sehr ins Detail. Ich dachte eher an eine etwas allgemeinere Argumentation, für die man selbst nicht zwangsweise Programmierkenntnisse braucht. Quasi auf einer höheren Entscheidungsebene, ohne dass man jetzt mit der tatsächlichen programmatischen Umsetzung argumentiert. Dabei dachte ich an so Punkte wie Wartbarkeit durch einen fremden Entwickler, oder Erweiterbarkeit der Anwendung. So etwas wären ja zum Beispiel Punkte die eher für Objekt Orientiertes Design sprechen würden, oder?

Du hast natürlich Recht, dass OOP quasi eine Spezialform der strukturierten Programmierung ist. Ich meinte wohl eher prozedurale Programmierung.

Das objektorientierte Design erlaubt uns flexibel zu modularisieren indem unabhängige Komponenten entwickelt werden können, die wiederverwendbar sind.