ich wollte mal fragen, was ihr so für erfahrungen gemacht habt,
speziell bei webprogrammierung, selbst geschriebenen frameworks etc.

ich benutze sehr oft Objekte, als Beispiel bei einem Framework:

In der eigentlichen Subroutine, die zu dem Request gehört, übergebe ich
dann nur das Context-Objekt, das alles beinhaltet, was die Subroutine braucht.
Das Context-Objekt kontrolliert, wann der Header geschrieben wird;
in der eigentlichen Applikation muss man sich darum nicht kümmern,
kann es aber beeinflussen.

Wenn man keine Objekte benutzt, sondern einfache Datenstrukturen,
muss man immer sicherstellen, dass auch das drinsteht, was
erforderlich ist. Zudem muss man statt Methoden Funktionsaufrufe
machen, entweder mit dem vollen Namen oder indem man die
Funktionen importiert, was den Namensraum zumüllt und wobei die
Kontrolle verlorengeht, welche Funktion von wem überhaupt aufgerufen
werden kann/darf.
Ausserdem erhöht es die Modularität, d.h., man kann die einzelnen
Teile auch woanders verwenden.

Ich finde, es gibt genügend CPAN-Module, die nicht objektorientiert
sein müssen/sollten, da sie einfache Funktionen zur Verfügung stellen,
die in sich geschlossen sind und nicht von anderen Programmteilen
abhängig sind, aber in einem Framework sind Objekte auf jeden
Fall von Vorteil.

Wie seht ihr das? Gibt es Fans von prozeduraler Programmierung,
die damit schon grössere Frameworks geschrieben haben?\n\n

<!--EDIT|pq|1180882401-->

Hallo,

das hat jetzt erst mal nichts mit Webprogrammierung zu tun, aber ich finde, die C-Standardbibliotheken sind gutes Beispiel.

Da gibt es viele nützliche Funktionen, die wunderbar ohne Objektorientierung auskommen, (memset, strstr), und andere, bei denen OO praktisch wäre (getopt, strtok).
Die größeren C-Bibliotheken, die ich in letzter Zeit benutzt habe (z.B. imlib2) haben meistens in irgend einer Form OO imitiert. Mehr oder weniger hässlich.

Meine persönliche Schlussfolgerung daraus ist, dass sich für wenig Funktionalität OO noch nicht lohnt, aber wenn sich eine geeignete Abstraktion herauskristallierst, verwende ich die auch.

Bei kleinen Webanwendungen mache ich das ganze meist Prozedural, größere Projekte verwenden Catalyst und sind Objektorientiert. Und wenn die kleinen Projekte größer werden, beiße ich mir in den Allerwertesten, weil ich nicht von Anfang an Catalyst genommen habe (z.T. kannte ich das "damals" noch gar nicht) ;-)

Bei den CPAN-Modulen stimme ich zu, dass es einige gibt, die auch ohne OO auskommen würden, zumindest für meine Anwendungen. Z.B. Digest::MD5 habe ich noch nie objektorientiert benutzt.

[quote=moritz,03.06.2007, 17:54]Da gibt es viele nützliche Funktionen, die wunderbar ohne Objektorientierung auskommen, (memset, strstr), und andere, bei denen OO praktisch wäre (getopt, strtok).
Die größeren C-Bibliotheken, die ich in letzter Zeit benutzt habe (z.B. imlib2) haben meistens in irgend einer Form OO imitiert. Mehr oder weniger hässlich.[/quote]
Für den geneigten C Programmierer eventuell von Interesse:
Objektorientierte Programmierung mit ANSI-C

[quote=moritz,03.06.2007, 17:54]Und wenn die kleinen Projekte größer werden, beiße ich mir in den Allerwertesten, weil ich nicht von Anfang an Catalyst genommen habe (z.T. kannte ich das "damals" noch gar nicht) ;-)[/quote]
ah, guter punkt, der für OO spricht. ein framework wächst ja von
natur aus, und ich habe schon so oft subroutinen umgestellt von
der übergabe a la "func($foo, $bar, \@baz) auf
"func({foo => $foo, bar => $bar, baz => \@baz})
da man bei der ersten variante gezwungen ist, immer alle parameter
zu übergeben, auch wenn sich am programm was ändert. ggfs. muss
man dann undef übergeben.
übergibt man eine datenstruktur, erledigt sich das. und wenn man
ein objekt hat, ist die interne datenstruktur egal und kann bei einer
änderung der datenstruktur idealerweise die API so lassen, da man
ja nicht direkt auf die datenstruktur des objekts zugreift (auch 'idealerweise' =)

Hallo

Ich für meinen Teil - das ist somit nicht wirklich eine Aussage - benutze Perl nur OO.
Es spart die Doku da man in den einzelnen ".pm" nur doch die Variablen und Funktionen aussagekräftig benennen muss.

Wer sich mal die Mühe macht Exporter.pm zu benchmarken kennt einen weiteren Grund.

Gruß
Kristian

PS: pq ich bin erstaunt, ich dachte das Thema war vor 10 Jahren schon durch.

[quote=pq,03.06.2007, 18:20]ah, guter punkt, der für OO spricht. ein framework wächst ja von
natur aus, und ich habe schon so oft subroutinen umgestellt von
der übergabe a la "func($foo, $bar, \@baz) auf
"func({foo => $foo, bar => $bar, baz => \@baz})
da man bei der ersten variante gezwungen ist, immer alle parameter
zu übergeben, auch wenn sich am programm was ändert. ggfs. muss
man dann undef übergeben.[/quote]
Das muss nicht schlecht sein...

my $rs = $dbic->resultset($source)->search(undef, { columns => \@c });

Ich denke auch nicht, das irgendetwas darunter leidet, denn in gewisser
Weise ist das ja auch Struktur.

Vorgestern habe ich ein kleines neues Projekt angefangen und dachte mir,
dass es ohne OO auskommen würde... und zum X-ten Mal musste ich
feststellen, dass ich falsch liege. Gestern habe ich es komplett umge-
schrieben, weil es mit OO einfach besser geht. Das Feine an OO ist, dass
man den Kontext beliebig oft wechseln kann, ohne die Übersicht zu
verlieren.\n\n

<!--EDIT|opi|1180891547-->

[quote=kristian,03.06.2007, 18:23]PS: pq ich bin erstaunt, ich dachte das Thema war vor 10 Jahren schon durch.[/quote]
und mit welchem ergebnis? =)

ich möchte nur ein paar erfahrungen hören, da ich selbst wie gesagt
eine etwas grössere applikation/framework nur mit OO machen
würde, aber es gibt auch genug leute, die anders denken; und
ich möchte einfach auch mal eine schön geschriebene applikation
in perl sehen, die ohne OO auskommt und die einfach erweiterbar ist.

[quote=opi,03.06.2007, 19:23]Das muss nicht schlecht sein...

my $rs = $dbic->resultset($source)->search(undef, { columns => \@c });[/quote]
nun ja, das ist OO. das wichtigste argument ist das objekt. und
solange sich die zahl der parameter in grenzen hält, ist das ja
durchaus ok. wie du siehst, wird als zweites argument ein hash
mit weiteren optionen übergeben.

Hallo

Quote

und mit welchem ergebnis? =)

Wir hatten uns damals AFAIK für OO entschieden, es gab nebst dem was heute wirklich wichtig ist, Wartbarkeit, Übersicht, Notwendigkeit und Umfang von Doku, damals Argumente wie CPU <=> Ram.
Das interessiert heute keinen mehr, die Zeit die wir damals mit Benchmarken vertan haben ist bei der derzeitigen Hardwareentwicklung und den Preisen für den nächst größeren Server aus wirtschaftlicher Sicht sinnfrei. Schön, wenn man weiß was schnell ist, notwendig ist es (im 08/15 Fall) nicht mehr.
(Bevor jetzt Widerspruch kommt, ich habe Scripts mit 15 Mio Request/Monat im Einsatz das ist aber nicht 08/15)

Auf die übersichtliche und lesbare Anwendung in Perl, die nicht OO ist wirst du IMHO lange warten. Ich kann sie mir nicht vorstellen du kannst es nicht, ev. findet sich ja jemand der uns "bekehrt" aber ich halte es für unwarscheinlich.

Gruß
Kristian

haengt davon ab, was damit gemacht werden soll

Bei module bevorzuge ich gelegentlich OOP, waehrend das Hauptprogramm fast immer prozedural ist (bzw. prozedural mit verwendung von Objekten).

Bei Modulen, in denen auf ein datum mehrere Aktionen ausgefuehrt werden, finde ich in OOP besser (z.B. HTC, Net::FTP, DBI).

In Modulen, die immer nur eine Aktion auf ein Datum ausfuehren, bevorzuge ich Funktion (z.B. Encode, Data::Dumper, Storable), weil da OOP IMHO ein overkill ist.

Bei Frameworks halte ich meist eine Mischung aus beiden Wegen fuer optimal, weil es da haeufig beide Wege gibt.