Letztlich ist das ein riesengroßes Fass.
Ich würd noch einen Schritt weitergehen und sagen, dass Java eine OO- und framework-orientierte Sprache ist.
Gibt ja seit den frühen 70ern diese art vs. science Debatte.
Ich bin sehr stark für den ingenieursmässigen Ansatz und gegen den persönliche-Kreativitäts-Ansatz.
Dies hängt natürlich mit den persönlichen Erfahrungen ab, die man macht.
Ich habe einfach zu oft business-relevante größere Notes Projekte weitergeführt, die dem Gehirn eines Entwicklers entsprungen sind, unvollständig dokumentiert waren und in denen es klare Fallen gab. Wo Administratoren eben auch oft nicht mehr in der Lage waren, das gute Stück am Leben zu halten, weil man dazu eben das spezifische Gehirn des Entwicklers brauchte. Das hat mich in diese Richtung gebracht.
Glaub, dass es bei typischen Total Cost of Ownership Themen wie maintainability, non-functional requirements und Erweiterbarkeit deutliche Lücken im Verantwortungsbewußtsein der "Notes ist so einfach"-Fraktion gibt.
Richtig eingesetztes OO ist bei diesen Punkten sicher der bessere Ansatz.
Richtig eingesetzt ist natürlich unscharf und jeder macht nicht in jedem Projekt alles richtig.
Klar kann man mit allen übertreiben. Ich kannte Leute, für die jede Schnittstelle zwischen Layern, die nicht durch eine xml-Kommunikation "völlig entkoppelt" waren als eine zu starke Abhängigkeit ansahen. Das ist natürlich völlig übertrieben.
Bin mir nur inzwischen ziemlich sicher, dass sich die Investition in pattern-basiertes OO lohnt.
Genau wie die Investition in gut durchdachte Experten-Frameworks wie z.B. struts oder tapestry als Webframeworks oder ibatis/hibernate für die Integration von RDBMS oder Eclipse Rich Client Platform als Basis für RichGUIs.
Auf de.comp.lang.java gibt es eine relativ typische und wiederkehrende Debatte. Da geht es um Webservices. Und jemand wirft dann ein, dass man das viel "einfacher" über sockets implementieren könnte. Da meint aber auch die Mehrheit, dass dies in vielen Fällen nicht einfacher ist, sondern der "einfacher"-Forderer die Komplexität der Entwicklung eines robusten Protokolls (muss man bei socket-Lsg implementieren) unterschätzt, besonders wenn dieses am Ende noch Querschnittsfunktionen wie Sicherheit und Transaktionen unterstützen soll.
Genauso ist es bei OO vs. Prozedural. Was zunächst einfacher aussieht, ist auf mittlere Sicht oft genau nicht einfacher. Viele Organisationen haben das erkannt. Das heisst aber nicht, dass man jede Zeile code unter der Maßgabe der totalen OO-Erweiterbarkeit schreiben sollte.
Wie Thomas Völkl hier mal sehr richtig angemerkt hat, geht es beim Design darum abzuschätzen, wo Änderungen wahrscheinlich sind und genau dort braucht man eben Flexibilität.
Es gibt aber auch Stellen, wo static ok ist. Besonders zahlreich sind sie nicht. Schon zahlreicher sind die Stellen, wo es für die öffentliche Schnittstelle eines Objekts kein Java-Interface gibt, um dies gegebenenfalls später mit Strategy Pattern zu erweitern.
Gruß Axel
Umfrage
Thema: OO Umfrage (Gelesen 3612 mal)