Sonstiges > Offtopic

OO Umfrage

<< < (2/4) > >>

Marinero Atlántico:
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

Manfred Dillmann:
Hallo Axel,

danke für Deine Ausführungen - ich bin (wie immer) beeindruckt.

>>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.<<

Alleine darüber könnte man ja Bücher schreiben. Etwas schuld hat da Notes selbst - das berühmte "Rapid Prototyp'ing" liefert schnell (zu schnell?) vorzeigbare Ergebnisse und da gibt es of keine Phase der Planung - man fängt einfach an und schaut, wie weit man kommt.

Ist aber auch (heute) durchaus schwierig: Wenn man dem Kunden erzählt, dass man sich jetzt erst mal ein paar Tage Gedanken über die Struktur der Anwendung (z.B. auch für zukünftige Erweiterungen) macht - das will niemand bezahlen. Zumindest bei Notes und kleineren bis mittleren Applikationen. Man tut sich damit zwar selbst einen Gefallen, aber die Kunden wollen eben genau die geplante Anwendung - mehr nicht. Und über eine leichte Erweiterbarkeit in der Zukunft macht man sich jetzt noch keine Gedanken. Das geht dann bestimmt auch "irgendwie". In bestimmten Fällen könnte das nahezu in einem vollständigen Rewrite enden - egal, jetzt wollen wir erst mal unsere geplante Anwendung... na, aber wem sage ich das?  ;)

Mal ganz losgelöst von OO oder nicht OO.

Gruß
Manfred

Semeaphoros:
.... und wenn der Rewrite kommt, ist es Zeit für OO ....

Marinero Atlántico:
Rapid Prototyping und OO ist an sich kein Widerspruch.
Die ganze lautstarke Agile/xTreme Programming-Bewegungen favorisieren im Grunde Ansätze, den Usern möglichst schnell einen Prototypen zur Verfügung zu stellen.
Refactoring zielt auch in diese Richtung. Man kann ja inflexible Lösungen schnell in mehr OO-Lösungen refaktorieren (innere Struktur der Anwendung ändern bei gleichbleibender Funktionalität).
Ein bischen mehr anwendungsanalytische Vorarbeit ist aber wohl für einen OO-Ansatz notwendig.
Zu viel Planung ist aber auch nicht gut, weil man einfach nicht alle Probleme übersehen kann.
Ich kann auch nicht verschweigen, dass zumindest bei meinen mehr spielerischen Lernanwendungen die zahlreichen neuen Arbeitsmethoden und Frameworks mich z.Zt. extrem ausbremsen.
Test Driven Development, Tapestry statt struts, Hibernate statt Entity EJBs oder/und DAO, Hipersonic SQL statt mySQL, JBoss, XDoclet.
Samstag befand ich mich jedenfalls in einem sehr realen Innovation Dead Lock (TM) mit meiner Scheiss_Auf_Websphere-Politik.  ;D
Sagt aber eben auch noch nix über die generelle Machbarkeit aus.

Jedenfalls sind in den letzten Jahren eine Menge Dinge entstanden, die einfach zu gut sind als das man sie mißachtet. Aber es ist anstrengend.
OO ist heute eben zu komplex als dass es eine best practice gibt und dann kann man "es".
Glaub aber, dass die Richtung in vielerlei Hinsicht stimmt.

Axel
 

animate:

--- Zitat von: Manfred Dillmann am 28.02.05 - 13:50:43 ---Wenn man dem Kunden erzählt, dass man sich jetzt erst mal ein paar Tage Gedanken über die Struktur der Anwendung (z.B. auch für zukünftige Erweiterungen) macht - das will niemand bezahlen. Zumindest bei Notes und kleineren bis mittleren Applikationen. Man tut sich damit zwar selbst einen Gefallen, aber die Kunden wollen eben genau die geplante Anwendung - mehr nicht.

--- Ende Zitat ---

Huh?
Selbst bei kleineren bis mittleren Projekten halte ich es für unabdingbar, mir erstmal Deganken dazu zu machen.
Angefangen bei den Gedanken zum dem was der Kunde will und aufgeschrieben hat und dem, was er will, aber nicht aufgeschrieben hat (mindestens 30%). Wenn er überhaupt was geschrieben hat... IMHO macht eine gute Analyse beim Kunden schon ziemlich was her und er merkt, dass das gar nicht mal so schlecht ist, wenn sich jemand mal Gedanken macht, bevor er loswerkelt. Zumindest dann, wenn ihm durch deine schlauen Fragen, mit denen du Ungereimtheiten oder nicht formulierte Wünsche aufdeckst, das ein oder andere Licht aufgeht.
Zahlen wird er dafür wahrscheinlich wirklich nicht wollen, aber da kommts dann halt drauf an, wie du es verkaufst...

Ich vermute aber, ich habe dich da missverstanden, Manfred. Ohne dich jetzt auch nur im Entferntesten zu kennen hätte ich dich nämlich schon als einen 'Planer' eingeschätzt.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete