Luca | August 24, 2005
Da qualche settimana sono disponibili le slide di tutte le sessioni parallele che si sono tenute durante i due giorni della Java Conference; so possono trovare partendo da qui.
Io ho seguito la sessione sul design e le slide le potete trovare seguendo questo link.
Luca | August 3, 2005
Gli accessor nella loro più semplice e comune forma non sono altro che la mappatura uno a uno dei campi di una classe verso l’esterno, e questo risulta in un clamoroso caso di violazione dell’information hiding. Un’adeguata incompetenza di fondo fa si che Java Bean si trasformino in oggetti di business “senza business”, e che viaggino indisturbati in tutto il sistema, dallo strato di persistenza allo strato di presentazione.
questo porta a due situazioni correlate:
- il mio sistema non ha oggetti di business reali. Ho sostituito gli oggetti di business con data-store (value object), quindi non ho veri business object ma semplici strutture dati (come le care struct del C) che viaggiano di qua e di là .
- il mio sistema non è OO . Avendo strutture dati che si muovono in giro, non sto seguendo il paradigma OO ma il paradigma imperativo scritto con un linguaggio OO!!! Quando infatti sposto value object per il sistema, non chiederò servizi agli oggetti, ma dirò ad ogni oggetto cosa deve fare per me….non avrò quindi un network di oggetti che colaborano, ma un insieme di contenitori di funzioni da me chiamate arbitrariamente per ottenere di volta in volta i dati che mi servono.
I Java Bean devono quindi fermarsi allo strato di presentazione: lì hanno la loro dignità e lì devono fermarsi; una diffusa incompetenza di fondo sul design ha invece trasformato questi data store nel perno di tutte le applicazioni, forzando implicitamente il design ad un non-design.
E’ però curioso che quando si sollevano obiezioni su questo utilizzo dei bean, le persone facciano resistenza: puoi ragionare su information hiding e principi di design ma alla fine l’abbandonare i cari value object dominatori del sistema evidentemente li spaventa….che forse come consiglia Ugo Landini il paradigma imperativo sia troppo radicato nella nostra cultura per sostituirlo con un corretto paradigma Object-Oriented ?