Polymorphic Rants

Una classica architettura (per me) che ho usato (e che sto usando tuttora) per salvare su database è avere una serie di bean (POJO) con un sacco di begli accessor che mi violano l’incapsulamento che vengono passati ad un oggetto (ultimamente ho implementato un bel DAO-Data Access Object, se non ero-) che si occupa di salvare. L’oggetto è una sorta di Manager del db per QUEL determinato oggetto.

Mi spiego:

Se ho un oggetto Persona:


class Persona {
private String nome;
private int eta;
//accessor dei campi
}


avrò un PersonaManager:

class PersonaManager implements IPersona {
public void salvaPersona(Persona persona){
//CODE CODE CODE
}

public Collection leggiPersoneAnziane(String limiteEta) {
//CODECODECODE< }
[...]
}
insomma: quello che a che fare con la Persona, lui lo gestisce.In questo modo cerco di astrarmi dal basso livello del database: se domani passo da SQL+JDBC (o ADODB o cosa altro si usa in casa MS) ad un layer di persistenza ad oggetti non è un problema...nuovo oggetto che implementa l'interfaccia e a basso livello lui saprà cosa fare per leggere/scrivere sul db; il client che chiede il salva non cambia di una virgola.

Però..c'è un però...

1. c’è qualcosa che non mi soddisfa
2. la responsabilità di salvarsi non potrebbe essere della Persona stessa ?(Persona salvati!!) i controller diventato grassottelli (sanno che devono istanziare il DAO,chiamare il tal metodo….ma quante cose!!!)

l’idea al centro della mail è quella di usare il Proxy Pattern per fare questo (credo di averlo letto da qualche parte tempo fa, ma non ritrovo più il documento…)

l’oggetto Persona ha i suoi metodi scrivePersona(), leggiPersona() e così via…..sono questi metodi che implicitamente istanziano il DAO !

quindi:

class Persona {
public void scriviPersona() throws MiaEccezione{
IPersona personaManager = new PersonaManager();
personaManager.scriviPersona();
[....]
}


in questo modo riesco anche a tenere tutti i campi incapsulati, non essendo obbligato a priori a dare accessor a tutto (lo darò solo a quello che mi serve..forse…)
Ho anche l’impressione che seguendo questa strada si ottenga un design molto più OO che quello che sto attualmente facendo; ora, aldilà di implementare n’interfaccia (WOW!!Cool!!!) ho una serie di oggetti che interagiscono in modo alquanto procedurale (la servlet-il controller- piglia i campi dalla request, li pusha -fa sempre molto cool italianizzare alcuni termini inglesi, vero ?- in Persona, istanzia il DAO, passa persona al DAO e gestisce il risulato/eccezione generica)
Persona tende a non essere più solo un odiato datastore ma qualcosa di più concreto..o mi sbaglio ?

il dubbio è ….sto “sopra-ingegnerizzando” il problema ? aggiungo complessità inutile (guai per noi agilisti!! ) ? l’idea è tutta sbagliata ?

sto ancora cercando un feedback a proposito….qualcuno mi può aiutare ?

Sempre più spesso mi rendo conto come la conoscenza superficiale sia fonte di danno; ne ho un esempio limpidissimo per quel che riguarda HTML, DHTML, DOM e tutta la compagnia. Lo ammetto: ho imparato Javascript, DHTML e a muovermi nel DOM alquanto alla buona, nei primi progetti a livello professionale a cui ho partecipato. Come si dice *so arrangiarmi*..ma quando ci sono i problemi di compatibilità cross-browser, quando mi faccio umiliare dall’ HTML Validator del W3C (ci manca questo attributo!! non hai definito il content-type!!! ma cosa stai facendo, specie di utonto ???) mi rendo conto come la mia conoscenza sia adatta per passare un pomeriggio a casa con l’influenza. La colpa è anche mia: non ho mai approfondito queste cose, preferendo altri argomenti (però francamente trovo più interessante l’Open-Close Principle piuttosto che tutto lo scibile di Javascript.) In questo devo dire che i parser dei browser non mi aiutano: Explorer prende tutto e di piu’ mentre FireFox e’ piu’ ligio agli standard W3C ma su alcune cose chiude un occhio…fortuna che c’è il DOM Inspector e Il Javascript Console insieme a FireFox !!!!