Originariamente inviato da luca200
Gli eventi non esistono. Se togli la pressione del tasto 'stop', il cui unico risultato può essere di stroncare l'esecuzione, non c'è modo per l'utente di interagire con lo script o la servlet (di M$ non parlo perché non conosco, ma finché si ragiona in termini di protocollo HTTP non vedo cosa possa cambiare). Per questo dicevo che l'approccio OO è superfluo.
Non sei d'accordo?

Di veri eventi non ne esistono ma si può immaginare che ci siano, e programmare OOP come se ci fossero (e senza usare Javascript o Flash).
.NET (e prima ancora alcuni framework Java) ha sfruttato questo "modo di pensare" nel sistema di templating di ASP.NET, ma la stessa cosa si può ottenere con PHP (a settembre butterò giù un po' di codice su cui sto lavorando a saltoni per mancanza di tempo).
Questo è un modo per sfruttare a pieno le caratteristiche dell'OOP, ma quando l'applicazione è mediamente complessa io trovo comunque utile (non indispensabile, ma utile) ragionare in termini di classi e oggetti.
Immagino sia una questione di abitudine però mi costringe a pensare all'applicazione molto prima di cominciare a buttare giù codice, con il risultato di avere meno ripensamenti, meno modifiche incontrollate (tocco qualcosa qui e sconvolgo anche lì ...e così via).
Penso che questa sia la chiave di lettura del progressivo dilagare dell'OOP anche nel WEB..in più come ha detto Gianni, io trovo che sia soprattutto un modo comodo di pensare all'applicazione.
Certo che se mi chiedono di consegnare qualcosa di totalmente inedito per dopodomani mi metto a farlo in maniera pazialmente o totalmente procedurale ma, avendone il tempo, personalmente trovo più redditizio e lungimirante progettare a oggetti.