@Semaphoros,
1. Dykstra sagt in diesem paper, dass gotos in Assembler eine Berechtigung haben.
2. Deine strukturierte Programmierung 201 Beiträge sind wertvoll.
3. halte ich deine Reaktion für hm irgendwie übertrieben.
4. Meine alte Paranoia kocht hoch, dass Leute mit fundierter Informatikausbildung mich als
- Freund von Java
- Freund von Webservices
- Freund von JSP/Servlets
- ca. 5 und steigend grösseren Java open Source frameworks
- Eclipse user
- OO-Pattern-Freund
- don't code take google
- Unified Process Anhänger,
als irgendwie neureichen Modegeck ansehen.
Das ist aber einfach nicht wahr, weil:
- ich habe meinen Mc Conell, Code complete
- ohne Studium von fundamentalen Prinzipien von verteiltem Rechnen und Datenbanktheorie und -praxis und 120 weitere Sachen helfen einem weder SOAP noch Enterprise Java Beans irgendwie weiter. Das ganze Marketing-Geseiber es würde einfacher und man bräuchte dieses ganzes low level Quatsch nicht, ist komplettester Unsinn.
Auf diese Tour bekommt man auf jeden Fall keine akzeptabel performanten Anwendungen hin und vermutlich noch nicht einmal lauffähige Anwendungen. Man muß oft eine Etage in den Keller gehen und sich damit auseinandersetzen, was dort passiert.
Man kann auch nicht OO programmieren ohne ein vernünftig strukturiert programmieren zu können.
noch was:
Noch was: einen Schleifenkörper möglichst kurz zu halten ist nicht nur eine Frage der Uebersicht, sondern auch der Performance. Deshalb ist auch Vorsicht geboten mit Aufruf von Subroutinen anstelle der Ausprogrammierung einer Sequenz, da Subroutinen notorische Performance-Verschwender sind (keine Ahnung, welchen Preis man dafür in LotusScript zahlt, um das gleich mal klarzustellen).
Der Aufruf von Subroutinen kostet einen gewissen Performance overhead, ok. Das wird beim erzeugen von lustigen layers of indirection mit Klassen tendentiell noch verstärkt. Und wenn man dann noch nifty die Objekte auf verschiedene Tiers verteilt und coole xml-Layer verwendet möglicherweise potentiert (und das ist dann oft ein Problem).
Solange man aber keine vernünftigen empirischen Daten hat, wie lange jetzt Methoden/Funktions/Remote SOAP_RPC-Aufruf A dauert und sich überlegt, ob der overhead signifikant für den business case ist, handelt es sich dabei um eben theoretische Informatik. Ich glaub wir sind uns da einig. Manche Sachen kann man mit Erfahrung voraussagen. Ich bin aber ehrlichgesagt oft überrascht worden, seitdem ich eigentlich bei jedem Java-code den ich schreibe mir Milisekunden Werte hole (da die Messung selbst Zeit kostet, sind solche Werte natürlich nie genau, aber man kann auf jeden Fall immer vergleichen).
Ich habe starkes Mißtrauen gegenüber:
- Objekt Verteilung auf verschiedene Rechner um ihrer selbst willen
- Aufteilung von Subsystemen in Komponenten mit "sauberen" Interfaces (low coupling, high cohesion) um ihrer selbst willen.
Performance ist ein Punkt bei der Entwicklung. Es gibt nur ein nicht wegzudiskudierender trade off zwischen Übersichtlichkeit von code und Performance von code.
Das klassische OO-Prinzip ist: Sauberer code ist erst einmal wichtiger. Zumal man in übersichtlichen code auch leichter die realen performance bottlenecks findet. Da ist meiner Ansicht nach sehr viel wahres dran.
Die Praxis (und v.a. die Praxis mit Erfahrung) ist aber immer ein Kompromiss und nicht diese Schlagwörter. Ich baue oft frühzeitig Performance freundliche Infrastruktur (Objekt-Pools, Singletons, etc) bevor es nach der reinen OO-Lehre nötig wäre. Ich beherzige ca. 20 grundlegende oft programmiersprachenspezifische Regeln von performanter Programmierung direkt beim coden.
Trotzdem würde ich niemals (ausser in "onError goto Fehler") goto verwenden, da ich in diesem Leben niemals Assembler programmieren werde.
Gruß Axel
