Utilizzare metodi e proprietà di altre classi

[Santino83_02]

Originariamente inviato da chumkiu
Nella classe Articoli non devo vedere alcuna sintassi specifica (nemmeno una select perché il sistema di archiviazione dati scelto potrebbe non supportarlo), altrimenti è tutto vano.

Vero, se uno scrive bene può anche pensare di arrivare ad avere delle ModelDAO completamente astratte dal db e quindi utilizzanti solo metodi di alto livello del db sottostante. Ma appunto, devi sapere programmare alla grandissima, perchè coprire tutti i casi possibili di query che uno possa voler fare, non è facile per niente. Vediti per esempio la documentazione di Hibernate ad esempio: dalle Criteria alle HQL proprietarie, si è cercato appunto di astrarre il db sottostante in maniera che classi d'alto livello non sappiano proprio una ceppa di quello che hanno sotto... ma i risultati sono molto complicati da capire e gestire correttamente, e sei cmq legato ad hibernate nel caso specifico. Ci sono framework che risolvono analizzando le strutture delle tabelle e facendo i controlli del caso, ma è un livello di programmazione che di certo only non è in grado di attuare

[chumkiu]

Ci sono framework che risolvono analizzando le strutture delle tabelle e facendo i controlli del caso, ma è un livello di programmazione che di certo only non è in grado di attuare

E allora è inutile tutto. Che faccio a fare decine di factory, classi e implementazioni se poi nella classe Articolo ci sparo un metodo con dentro un mysql_query("select/insert from tabella...."); ?

[LeaderGL]

Originariamente inviato da chumkiu
Non mi è chiaro questo... perché si costruiscono per il database bellissime interfacce, un'ereditarietà delle classi ben strutturata e persino una factory... per poi creare una classe che si chiama Mysql_Articoli? E se ho supporto a 6 database e 200 oggetti nel sistema (Articoli, news, users, pages, prodotti, nazioni, regioni, citta, banner, immagini, manifestazioni, eventi, parametri, ecc.) mi devo costruire 1200 classi? E anche dopo averle costruite, se voglio aggiungere un misero database che nel frattempo hanno inventato mi devo scrivere altre 200 classi? Nella classe Articoli non devo vedere alcuna sintassi specifica (nemmeno una select perché il sistema di archiviazione dati scelto potrebbe non supportarlo), altrimenti è tutto vano.

Ti do ragione in tutto. Infatti non è la strada che io personalmente avrei mai preso ed all'inizio del thread stavo cercando di spostare l'attenzione su questo problema ma siccome hanno deciso di utilizzare il pattern dao mischiandolo malamente al pattern factory ho cercato di mettere in luce gli errori che si stava commettendo; proponendo al tempo stesso una implementazione che separasse perlomeno i due pattern.

Questo perchè seguendo la strada che hanno preso non solo avranno il problema che stai citando ma oltre a tutte le classi dai delle varie componeneti (articoli, news, etc) dovranno modificare anche tutte le classi di gestione del database.

Però purtroppo sembra che ci si sia fissati col dover portare avanti quest'accozzaglia di factory/dao complicando la vita a chi aveva chiesto consiglio.

[oly1982]

http://www.youtube.com/watch?v=tQAiMF_TXcg

[chumkiu]

Possiamo disquisire teoricamente. Allora, sempre teoricamente, non dobbiamo porre limiti alla capacità del programmatore o al tempo a disposizione.

Perché praticamente, le soluzioni sono due:
- o ti affidi a classi o framework che già fanno tutto (lo Zend_Db_Table per esempio è ottimo)
- o fai qualcosa a metà tra la praticità e riusabilità.

Nel secondo caso mi vanno bene anche le query dirette dentro la classe. Ma a quel punto via tutto il resto che è perfettamente inutile. Si fa una classe in cui si passa al costruttore il nome del database a cui fa riferimento, e se non c'è si prende il nome di default. Fine della storia. Riusabile e pratico se utilizzi sempre e solo mysql. Al limite puoi fare una classe astratta in cui descrivi il metodo del costruttore e la estendi. Ma nulla di più.

Parlo con cognizione di causa. Ho fatto un paio di classi per tabelle di database (senza intercambiabilità di Engine, solo mysql), che fa anche left join automatici e un pò di figherie. E' un lavoro complesso e infinito perché ogni volta esce fuori una opzione che non hai previsto. Da' soddisfazioni sicuramente, è un ottimo esercizio di stile... ma il risultato non può essere equiparato a quello di un progetto in cui partecipano migliaia e migliaia di persone. Diciamo che è molto comoda e mi ha permesso di gestire oggetti complessi (che puntano a più tabelle) in modo molto ma molto veloce. Ma da qui a dire che è fatto a regola d'arte... c'è un abisso.
Poi ho visto lo Zend_Db_Table che fa lo stesso, ma con 1000 opzioni in più e in aggiunta pure con l'astrazione dell'Engine... che devo fare? =)
Quelle mie due classi me le tengo per casi particolari... per tutto il resto c'è Zend

[oly1982]

Intervengo io per precisare lo scopo del topic che ho aperto.

Io non sono un programmatore o perlomeno nella vita ho fatto altri studi totalmente differenti (Economia e commercio) e mi sono avvicinato al mondo della programmazione web perchè una volta volevo costruirmi un sitarello... da quel giorno mi è nata la passione.

Credo che (o forse sono un illuso) che nella programmazione php di tipo procedurale me la cavo abbastanza bene, solo che molti consigliano, per fare le cose in grande, di programmare ad oggetti.

Così armato puramente dalla passione ho buttato giù le mie prime righe con questo nuovo approccio.

Sono perfettamente consapevole che spesso occorre utilizzare cose fatte dagli altri e che sono molto più efficienti ed affidabili (zend) ed è mia "ambizione" riuscire ad utilizzare questi framework.

Solo che essendo totalmente a digiuno di OOP volevo iniziare a capirlo facendo un qualcosa di "concreto" seppur "inutile" da un punto di vista applicativo... pertanto il DAO, la gestione gli articoli o qualsivoglia applicazione costituiscono per me un puro PRETESTO per scrivere codice OOP e non ho nemmeno lontanamente la pretesa di scrivere il codice perfetto (... la solita cosa che si dice di reinventare la ruota... e farla in malo modo).

Quando riuscirò ad apprendere e familiarizzare un pò con la OOP vorrei passare ad utilizzare un framework.

Molte delle cose dette (DA IGNORANTE!!!) le condivido. Io sono cosapevole che (almeno nel breve termine) non userò nessun altro DB che non sia MySql e quindi: il Factory, il DAO che mi sceglie il tipo di DB e l'interfaccia che "impone" agli extends i metodi da implementare sono un qualcosa che sto sviluppando "inutilmente"... se non per lo scopo "didattico" di capire cosa siano classi astratte, interfacce, estensioni... etc etc.

Spero al più presto di familiarizzare con questo nuovo approccio... e mi auguro che lastrada DIDATTICA che ho deciso di prendere sia quello giusta.