nicht angemeldet
Hi Wolfgang,
kann mir mal jemand logisch erklaeren, warum viele
Leute bei der Frage 'strukturiertes' contra 'objektorientiertes'
Programmieren so schwarz-weiss sind, bzw. warum diese
Frage ueberhaupt aufkommt?
Hm. Vielleicht haben diese Leute noch kein Real-World-Projekt durchgezogen? Sicher, OOP hat Vorteile, sogar ziemlich viele. Aber wie du bemerkt hast, es ist kein Allheilmittel. Natürlich kann man alles in Klassen abbilden, wenn man es darauf anlegt, aber manche Sachen gehen mit prozeduraler Programmierung einfach schneller, pragmatischer, einfacher, und wartbarer.
Kleine Begriffsklärung nebenbei. "Strukturiert" bezieht sich auf den Codierstil, "prozedural" ist das Gegenstück zu Objektorientierung. Strukturieren muss man auch bei OOP, sonst gibt es (hoffentlich) Ärger mit dem Projektleiter.
Hintergrund: Alle Nase wieder muss ich mich mit jemand
darueber streiten, wieso ich doch bitte nicht alles
objektorientiert mache... oder andersrum: warum ich es wage,
eben das zu machen, es sei doch nur Zeitverschwendung...
Kleines Beispiel aus dem aktuellen Projekt, an dem ich arbeite. Hier haben wir Images als BLOB in einer Datenbank abgelegt. Die Images werden über eine kleinen C++-Struktur (also eigentlich Klasse) beschrieben, in der z.B. die Content ID steht. Die Datenbank selbst wird über DCOM/OLE-DB angesprochen, liegt also auf einem anderen Rechner. Das Objektmodell, in dem die Image-Struktur modelliert ist, ist ein Zwitter. Einerseits wird sie vom Administrationstool (Composer) benutzt, also vom Client, andererseits von einer Extension-DLL vom IIS. Um den Code klein zu halten ist also keine Methode definiert, die das Image am Bildschirm zeichnet. Das erledigt eine kleine prozedurale Funktion im Composer, der hauptsächlich die Struktur übergeben wird, und das Rechteck, in dem gezeichnet werden soll. Das extra in einer Klasse zu kapseln würde Overhead produzieren und Performance kosten.
Ich hoffe die Erklärung war einigermassen verständlich ;-)
Tja....aber wie man es macht, so ist es falsch....
Nö. Richtig programmieren heisst schnellen und wartbaren Code zu schreiben. In der Praxis muss man pragmatisch vorgehen.
Natuerlich soll der OO-Programmierer spaeter dann voll
die Vorteile haben, wenn es an groessere Projekte geht...
aber stimmt das wirklich? Wieviele OO-Programmierer mussten spaeter dann doch wieder alles
anedern, schlichtweg, weil sie in der Planungsphase was vergessen
hatten
Das ist kein Merkmal von OOP, das passiert bei prozeduraler Programmierung genauso. Ich spreche aus leidvoller Erfahrung. Und bloss nicht dem Chef verraten, dass man gerade den Code von mehreren Wochen in die Tonne tritt, und in ein paar Tagen neu aufsetzt <g>
und vorallem, weil sie nach einiger Zeit ihre eigenen
Klassen nicht mehr kennen :))
Dafür gibt's UML-Tools, z.B. Rational Rose.
Gruß,
Martin