Sono abbastanza nuovo della programmazione ad oggetti quindi faccio una
domanda:
Per “progettare” una applicazione partite dalla progettazione del DB o
fate
prima uno schema delle classi?
Grazie a tutti
Bonzo
In generale dalle classi, nel caso specifico di ruby on rails e in
particolare di active record deve partire dal DB,
perchè si assume una corrispondenza uno a uno tra classi e db.
Paolo
Il 12/09/07, paolo foletto [email protected] ha scritto:
In generale dalle classi, nel caso specifico di ruby on rails e in
particolare di active record deve partire dal DB,
perchè si assume una corrispondenza uno a uno tra classi e db.
Paolo
La mia domanda era più in generale.
Quindi RoR va in controtendenza?
Bonzo
Il 12/09/07, Bonzo [email protected] ha scritto:
Per “progettare” una applicazione partite dalla progettazione del DB o
fate
prima uno schema delle classi?
Io ti consiglierei di fare uno schema della classi, anche appena
abbozzato,
su carta. Aiuta a ragionare, specie se sei nuovo alla programmazione. In
particolare ti consiglio la notazione UML per i diagrammi delle classi,
ma
se sei nuovo qualsiasi cosa andrà bene.
Ti consiglio di comunque di utilizzare un procedimento iterativo durante
lo
sviluppo di qualsiasi applicazione, e in particolare di applicazioni
rails.
Quindi dapprima decidi una funzionalità da implementare, poi passi a fare
uno schizzo delle pagine web che ti servono e infine pensi alle classi.
Dopodiché la implementi nel codice. Ad ogni iterazione di questo
procedimento aggiungi un “pezzetto” alla tua applicazione.
Questa metodologia è anche utilizzata all’interno di “Agile Web
Development
with Rails”, il più quotato libro su rails.
Spero di esserti stato d’aiuto!
se vuoi interpretarla così può anche essere,
in generale ti consiglio di partire dal modello delle classi
per capire il problema. Il software prima
di tutto dovrebbe risolvere la tua situazione che devi gestire
indipendetemente dai problemi di persistenza.
Poi nella pratica Active Record fa delle assunzioni sulla relazione
tra le classi e le tabelle,
Queste assunzioni permettono di sviluppare molto rapidamente
applicazioni semplici consone allo spirito di Ruby.
Se per qualche ragione vuoi fare delle cose un po’ complicate
il modello della classe non corrisponde alla struttura della tabella
oppure devi persistere una gerarchia che presenti degli attributi
diversi
tra i vari figli Active Record che è molto adatto nei casi semplici che
sono
oltre il 90% dei casi, non è adatto nel 10% restante.
ciao Paolo
Per me Ruby è il primo linguaggio OO (PHP doesn’t count) e non ho
formazione formale quindi cum grano salis…
Trovo che il più delle volte la nascita di un’applicazione - parlo della
struttura, l’idea, le fondamenta - è un processo mentale confuso e
incasinato. E iterativo.
Spesso volte il “problema” esiste già. Sotto forma di un capo, un cliente,
un’amico, o una frustrazione (“perché non c’è un sito che fa X,
diobbono???”). Il processo di traduzione del problema in codice è dunque
legato a fattori esterni. Molte volte questi “fattori esterni” sono
persone e perlopiù persone che non sanno molto di informatica. La loro
definizione del “problema” è lacunoso - spesso si inventano robe mentre lo
descrivono e la seconda volte che ci parli tocca rivedere quello che
avevi capito al primo giro - e lo stesso vale per la mia
interpretazione.
Finisco spesso per buttare giù classi e tabelle insieme, ma non mi è MAI
capitato di averci beccato la prima volta. Fai e disfi più e più volte.
Rails, per me, significa (maggiore) libertà in questo processo: costa meno
fatica rifare che stare a spremere oltremodo le meningi.
Detto questo, capita molte volte che mi devo fermare a metà del progetto e
fare una bella pensata a come cazzo ho strutturato le robe (sì, proprio
così: “ma cosa cazzo pensavi quando hai fatto così??? Idiota!”). A quel
punto finisco magari con carta e penna a fare diagrammi e a graphviz-are
schemi e flussi. Però all’inizio tendo a buttarmi e basta.
Il 12/09/07, David [email protected] ha scritto:
Detto questo, capita molte volte che mi devo fermare a metà del progetto e
fare una bella pensata a come cazzo ho strutturato le robe (sì, proprio
così: “ma cosa cazzo pensavi quando hai fatto così??? Idiota!”). A quel
punto finisco magari con carta e penna a fare diagrammi e a graphviz-are
schemi e flussi. Però all’inizio tendo a buttarmi e basta.
Anche io mi butto, ma i diagrammi me li faccio in testa :). E ragiono in
termini di classi, metodi e compagnia bella. Ruby on Rails tende a
semplificare tutto il processo di sviluppo e molte volte si tende a
“buttarsi” prima di pensare. Capita a tutti: purtroppo la mia breve
esperienza mi ha insegnato a riflettere un attimo prima di scrivere.
Quando
non mi sono fermato ho fatto troppi errori! 
On 9/12/07, paolo foletto [email protected] wrote:
se vuoi interpretarla così può anche essere,
in generale ti consiglio di partire dal modello delle classi
per capire il problema. Il software prima
di tutto dovrebbe risolvere la tua situazione che devi gestire
indipendetemente dai problemi di persistenza.
io mi sono trovato meglio partendo dalle tabelle, generalmente in forma
di
entity-relationship diagram.
partire con le classi mi portava a ignorare il fatto che poi i dati
stavano
in un db, con tutti i problemi connessi.
nell’implementazione mi ritrovavo a forzare un po troppo la visione a
classi
e fare casini.
pensare db-first può essere meno pulito concettualmente, ma secondo me
risparmia diversi problemi.
io di classi ne so poco, mentre ho studiato un po’ di ER.
Chi usa le classi come fa in caso di eredità ad arrivare ad i db?
Usa direttamente le classi figlio?
Bonzo
concordo con kiaroskuro, in particolare se sei all’inizio
parti con le cose semplici , disegnati dei semplici modelli ER,
che sono simili a dei diagrammi di classe.
Per soddfisfare la curiosità Active Record supporta una specie di
ereditarietà singola.
Parte dal presupposto di avere una classe con tutti gli attributi
possibili
di tutti i figli possibili
e un campo per deciderere il tipo di figlio, che ripeto è consono allo
spirito di semplicita di Ruby.
ciao Paolo
Il 12/09/07, Bonzo [email protected] ha scritto:
Chi usa le classi come fa in caso di eredità ad arrivare ad i db?
Usa direttamente le classi figlio?
Dipende caso per caso, ActiveRecord supporta nativamente la
SingleTableInheritance, praticamente “mappando” le classi sulla stessa
tabella e distiguendone il tipo a partire da una colonna di
quest’ultima.
Se non è possibile applicarla al massimo si spezza la catena di
ereditarietà
utilizzando delle “relazioni”. Ovviamente hai lo stesso problema coi
diagrammi ER, però lo risolvi “a monte”.
Infine supporta le “polymorphic associations” che permettono, pagando
pegno
al professore di basi di dati, di associare ad un modello qualsiasi
altro
modello all’interno della nostra applicazione.
Tipico è l’esempio del CMS: vi sarà quasi certamente una classe “contenuti”
che astrae ed uniforma articoli, immagini, sondaggi, ecc… Questa
classe
può facilmente essere facilmente realizzata utilizzando le polymorphic
associations.
Ragionare sulle classi non significa dimenticare che quelle classi
saranno
mappate su un DB, e quindi a sottovalutare il problema
dell’ereditarietà.
Io sono portato a pensare che i diagrammi ER siano una forma di
ragionamento
meno astratta, si occupano soltanto di dati e non dei metodi e delle
interazioni. Certo è che fanno bene il loro lavoro!
Ragionare sulle classi è qualcosa di più generale, è una metodologia che
funziona in qualunque contesto, dalla semplice calcolatrice fino ai
complessi middleware.
Tirando le somme i diagrammi ER sono direttamente “realizzabili” sul
database, mentre quelli sulle classi richiedono talvolta qualche
ragionamento in più. Allo stesso tempo i diagrammi sulle classi sono più
generali e “funzionano” qualsiasi applicazione tu debba sviluppare.
Probabilmente se conosci già i diagrammi ER e sei pratico con quella
metodologia di sviluppo, allora ha senso utilizzarla, mentre se devi
imparare qualcosa di nuovo… la progettazione partendo dalle classi è un
investimento migliore.
On 9/12/07, Bonzo [email protected] wrote:
Per soddfisfare la curiosità Active Record supporta una specie di
ereditarietà singola.
Parte dal presupposto di avere una classe con tutti gli attributi
possibili
di tutti i figli possibili
Mi potresti fare un esempio, non ho proprio capito bene.
Grazie mille
metti che hai una tabella che gestisce animali di vario tipo. avrai un
campo
‘apertura alare’ per gli uccelli e un campo ‘profondità massima’ per i
pesci
(si vede che non capisco una sega di animali dall’esempio). infine hai
un
campo che ti dice se quel record e’ un pesce o un uccello, così sai che
campi ha senso andare a guardarti.
Il 12/09/07, paolo foletto [email protected] ha scritto:
Mi potresti fare un esempio, non ho proprio capito bene.
Grazie mille
Bonzo
Il 12/09/07, chiaro scuro [email protected] ha scritto:
campi ha senso andare a guardarti.
ok, ho capito
grazie
bonzo
Il 12/09/07, chiaro scuro [email protected] ha scritto:
metti che hai una tabella che gestisce animali di vario tipo. avrai un
campo
‘apertura alare’ per gli uccelli e un campo ‘profondità massima’ per i
pesci
(si vede che non capisco una sega di animali dall’esempio). infine hai un
campo che ti dice se quel record e’ un pesce o un uccello, così sai che
campi ha senso andare a guardarti.
Ti sei dimenticato di aggiungere che ActiveRecord mappa gli oggetti per
tipo
automaticamente, quindi ci sarà un oggetto di classe Pesce e un’oggetto di
classe Uccello. Ovviamente puoi avere metodi e validazioni aggiuntive
rispetto alla classe base.
class Animale < ActiveRecord::Base
validates_presence_of :nome #ogni animale ha un nome, siamo alla
Disney!
def agisci
raise
end
end
class Pesce < Animale
validates_presence_of :profondita_massima
def agisci
“io nuoto”
end
end
class Uccello < Animale
validates_presence_of :apertura_alare
def agisci
“io volo”
end
end
e quando fai Animale.find(:all) ti fornirà istanze di Pesce e di Uccello
(anche Animale, se li metti sul database). E quindi potrai chiamare
“agisci”
su di loro senza problemi.
Non puoi descrivere questo con un diagramma ER: se dici che una colonna
non
può essere nulla, devi dare un’apertura alare anche al pesce, cosa non
molto
realistica. Oppure devi dire che un pesce può non avere una profondità
massima, cosa assurda nel nostro modello.
raise
Ma questo nel DB come verrebbe? Probabilmente perché so pochissimo di
activeRecord…
La spiegazione è chiara, ma non capisco che tabelle avrei nel db.
Bonzo
Il 14/09/07, Bonzo [email protected] ha scritto:
Ma questo nel DB come verrebbe? Probabilmente perché so pochissimo di
activeRecord…
La spiegazione è chiara, ma non capisco che tabelle avrei nel db.
Come ti è già stato spiegato nella mail di chiaroscuro, per quanto riguarda
la SingleTabelnheritance nella tabella basta aggiungere un campo type
alla
tabella ‘animali’ e ActiveRecord si occupa di tutto. ActiveRecord si
occupa
di discernere dal campo type la giusta classe da istanziare.
Invece nelle associazioni polimorfiche basta aggiungere un campo
‘resource_id’ di tipo integer, la “foreign key”, e un campo
‘resource_type’
di tipo string. In questo modo ActiveRecord riesce a istanziare la
giusta
classe quando accedi all’attributo ‘resource’. Qui c’è una bella
spiegazione:
http://wiki.rubyonrails.org/rails/pages/UnderstandingPolymorphicAssociations