Objektorientierung - Eine Fehlentwicklung der Informatik?

[Stefanie]

Hi,

der vermischt da Sachen, die so nicht direkt was miteinander zu tun haben und er verallgemeinert Erfahrungen, die ich so nicht bestätigen kann.

Klar hat er recht damit, dass sich in viele Softwareprojekten zu Tode geplant wird und nachher ein zu großes zu unflexibles Sytem heraus kommt, was der Kunde so gar nicht will und was nicht rechtzeitig fertig wird.

Daraus aber zu schiessen, man müsste nur das programmieren, was allgemein als  "quick and dirty" bezeichnet wird und alles wäre gut, ist in meinen Augen Humbug. Da sind ganz einfach andere, leichtgewichtigere Ansätze von Softwareprojektierung nötig, agile z.B. Auch dort gilt durchaus auch als ein Grundprinzip: Keep it small and simple.

Das kreative Austoben der einzelnen Entwicklers muss da einfach Grenzen haben, wo man in großen Teams und hohen Sicherheitsanforderungen programmiert und jeder sich schnell in die Strukturen des anderen einfinden können muss. Das Problem ist auch gar nicht mal "quick and dirty" eine Software zu entwickeln, die irgendwie funktioniert, sondern das ganze als Mensch dauerhaft geistig durchdringen zu können, bei eigener und fremder Software. Ist dies nicht möglich, kommt es schnell zu Fehlern, die obendrein schwer gefunden werden können. Die Zeit, die man beim Designen und Programmieren gespart hat, handelt man sich hier drei mal wieder ein.

In der Embeddedentwicklung hat sich Objektorientierung größtenteils noch nicht durchgesetzt und ich sehe die Nachteile jeden Tag. Zudem finde ich es geradezu lachhaft, es als Alternative zu betrachten, ganze Softwarepakete mal eben(?) neu zu schreiben, wenn sie so verwarzt sind, dass man nichts mehr daran ändern kann. Auch bei Neuentwicklungen kann die Wiederverwendbarkeit von bestehenden Modulen genau die Zeiteinsparung bringen, die die Nase eine Handbreit vor die des Konkurrenten bringt. Nein, Software muss nicht generell leicht änderbar sein - sie sollte nur leicht erweiterbar sein. Und das liefert ein Objektorientierter Ansatz.

Interessiert hätte mich auch noch, wie er mit "quick and dirty" eine ähnlich gute Testabdeckung erreichen will, aber vielleicht wird er ja in seinem Buch konkreter. Sein Bild eines Softwareentwicklers der alleine in seiner Bude hockt und über Nacht eine innovativ funktionierende Software zaubert, ist mir allerdings ein Graus. Keine Teamarbeit, keine Kommunikation, keinen Plan, ja die Kollegen gibt es heute noch. Es sind aber genau die, durch deren Software nie wieder jemand durchsteigt und die einem richtig fiese und schwer zu findende (und manchmal auch richtig gefährliche) Fehler bescheren.

Nun, wie bei allem im Leben gibt es hier halt auch nicht nur schwarz und weiss.

Gruss
Stefanie