Newsgroup: it.comp.appl.access
Titolo: (semi OT) Per quanto riguarda le CLASSI, mi (pare) di aver capito che il loro punto debole e' :

l'  incapsulamento dei dati. 
 
Usandole e studiandole mi sono accorto che e' impossibile soddisfare
completamente al requisito dell' auto contenimento  quando  il  loro  comportamento dovesse dipendere dai dati di un DB o piu' in generale
da grandi quantita' di dati. 
 
Mi  piacerebbe  sapere che cosa ne pensate in  proposito e, nel caso 
avessi ragione, se c' e'  qualche tecnica per risolvere il problema.
Non si sa mai.
 
Vi ringrazio
 

 da grandi quantita' di dati.
 
Stavolta non ho proprio capito cosa intendi con:
1) incapsulamento dei dati
2) requisito dell' auto contenimento (anche in relazione a grandi 
quantita' di dati, cosa intendi per /grande/ )
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

radica...@gmail.com
 formulated the question :

Non ho capito un c..., come sempre quando si parla di
aria fritta... ehm, volevo dire classi.
 
Bruno


Ma ...scusa, seriamente : davvero pensi che le classi siano aria 
fritta ? 
 
 
 

 quantita' di dati, cosa intendi per /grande/ )
 
Capito. No problem Maestro, guarda un attimo questo link se puo' 
aiutare a capirci : 
http://www.claudiomaccherani.altervista.org/web_dispense/File/OOP.pdf
 
 
a pag 13 e' descritto il concetto di incapsulamento. 
 
Fammi sapere

 fritta ? 
 
Le ho studiate, comunque qualche lustro fa, e ne ho viste
ben poche applicazioni.
E tutte le volte che le ho viste ho trovato delle complicazioni,
perlomeno formali, che con la codifica convenzionale
avrei sicuramente evitato.
 
Altro dirti non vo', ma la tua festa...
 
Bruno

 avrei sicuramente evitato.
 
Capisco. Ebbe', 
chiaramente  ognuno giudica in funzione delle esperienze sue. Poi
sai, dipende pure dal contesto in cui uno lavora e dalle esigenze.
Se  uno deve fare 1 kilometro al giorno per andare in ufficio non 
si compra un elicottero.
 
Invece : 
vorrei approfittare per chiederti una cosa che non c' entra niente
:-) 
 
Me  lo consigli un libro (anche in Inglese ma  se  e' in italiano
e'  meglio)  fatto BENE, chiaro, che spieghi a fondo e dagli inizi 
*tutti* i modi in cui ci si puo' connettere col VB (o col VBA) a 
un DB SQL  con i perche' e i percome ? 
 
Grazie
 
 
 
 
 
 
 
 


 
 
Tu che vantaggi pensi di poter avere, con l'utilizzo di Classi, nell'ambito 
dello sviluppo in Acccess?
Nelle applicazioni di database che sviluppi è molto il codice che hai la 
necessità di riusare?
 
Saluti.
 
 
 


Io personalmente non programmo solo Access. Programmo applicazioni Office.
Ossia scrivo applicazioni  che,  pur  essendo residenti comunque in Access 
(ma non necessariamente)  mettono  in collaborazione tutte le applicazioni 
Office tra loro. 
 
Applicazione =  software vba + access + excel + word + outlook. 
Poi i dati stanno un po' su Access, un po su SQL server, un po' su un 
altro DB tutto particolare sviluppato per noi, un po' su files excel un po'
su dati txt. 
 
In questo contesto le classi hanno una certa utilita', anche se certamente
se ne potrebbe fare a meno.  
 
... praticamente l' ideale sarebbe che  sviluppassi applicazioni VB autonome
che governano l' Office. Ma per  una serie di ragioni nel mio contesto lavorativo non lo posso fare. 
 
Allora che mi sono inventato ? Questo : 
produco applicazioni VBA il piu' possibile indipendenti dal contenitore
(Access). 
 
E che ce voi fa' ... uno guida con l' automobile che gli danno :-) 
 

 si compra un elicottero.
Non ho ben capito a chi tu stia rispondendo, comunque...
 
Mi piacerebbe conoscere il percorso che fai in elicottero
perché vorrei vedere se possibile compierlo con mezzi di
locomozione più convenzionali.
Sempre che tu, contestualmente, mi voglia mostrare come
un mio tragitto con mezzi convenzionali si possa compiere
meglio in elicottero.
 
È una sfida a suon di codice che ti propongo, per la quale
nominerei ad arbitri radicale001 & Co.
 
Bruno


Qualsiasi essa sia l'applicazione ci sono /sempre/ delle attivita' 
standard che debbono essere fatte e /poi/ c'e' la logica specifica 
dell'applicazione.
Immagina, per un momento, che Access non ci metta a disposizione, che 
so, la classe Form o la classe Recordset o l'oggetto Me
Tu sai, inoltre, che se ti dimentichi di definire delle variabili devi, 
normalmente, interrompre i test e fare le opportune correzioni e non 
parliamo del fatto del passaggio di parametri tra funzioni.
Prova ad immaginare un oggetto che ti consenta di evitare cio'.
L'utizzo di classi ti obbliga, inoltre, a fare un'altra cosa; /pensare/ 
l'applicazione prima di scriverla.


 nominerei ad arbitri radicale001 & Co.
 
Come vuoi e quando vuoi Bruno e scegli anche "l'arma" che ti pare.
Sebbene abbia ormai attaccato al chiodo la penna (intendesi quella roba 
per scrivere) da un po' di tempo (tranne qualche banale istruzione sotto 
pariGP).
;-)



Visto. Sono le cose "classi-che". ;-)
Non ho mai avuto problemi a "incapsulare" ne a gestire anche masse di 
dati notevoli (questo ovviamente e' sempre relativo a cosa si intende 
per /notevole/ )
Tra l'altro negli ultimi sviluppi accedevo alle proprieta' sempre 
attraverso un metodo (i setter e getter di java) anche perche' non avevo 
piu' proprieta' ma una, appunto, "blackbox" che le conteneva.


 piu' proprieta' ma una, appunto, "blackbox" che le conteneva.
 
PADRE ! 
HO CAPITO E NON HO CAPITO ! (cit. Guzzanti quando fa Aniene) :-)
 
Scusa Maestro : 
per es. ... mumble mumble ... immagina che devi fare una classe 
"persona"  che  in base ai dati che ci metti ti caccia fuori il 
codice fiscale. Ok ? 
 
Hai bisogno di incapsulare tutti i comuni e gli stati del mondo
(in teoria) o per fare una cosa fatta bene dovresti interfacciarti
col DB dell' anagrafe. E a quel punto addio autocontenimento : la
classe viene a dipendere da un db esterno. 
 
O no ? Dimme, che e' facile che non c' ho capito una sega.
 

radica...@gmail.com
 wrote :

Nell'estate del 2013 mi son messo attorno a un
SQL Server 2012 pensando di dover fare un certo
lavoretto che poi è sfumato.
L'ho installato su un PC mentre altri due erano
i client (un client Access, un client SQL Server).
Con l'Help e alcune pubblicazioni MS disponibili online
ci facevo anche il cappuccino tutte le mattine.
L'Help e le pubblicazioni MS sono fatte benissimo,
da non confondersi con l'Help di Office 2013
(che già dal 2007 non può nemmeno più chiamarsi tale).
 
Bruno

 ;-)
 
Beh, se proprio insisti te la posso inviare qualche paginetta
di codice da riscrivere facendo ricorso alle classi.
Poi m'interesserebbe vedere qualcosa di ponderalmente analogo
che sfrutta ab origine, per necessità naturale, 'ste classi!
Cose comunque di dimensione ridotta, da non doverci perdere
troppo tempo... ché perder tempo a chi più sa più spiace.
 
Bruno


 
Ottomila comuni so una cazzata (anche nel piu' scrauso pc moderno).
Ma comunque sebbene una cosa del genere sia "contenibile" nel senso che 
intendi tu il fatto che una classe, qualsiasi essa sia, abbia bisogno 
talvolta di "parametri" non mi sembra una gran cosa.
In una applicazione normalmente hai sempre bisogno di parametri.
Normalmente io li tenevo in una tabella fatta dal nome del parametro e 
da suo valore avevo una classe "parametri" che faceva tutto lei accedeva 
alla tabella si succhiava i parametri (in inizialize, teoricamente e 
quella che spesso viene definita classe statica) e amen. Tra l'altro 
sulla stessa struttura potevo infilare tutti i parametri "volanti" che 
volevo e per parametri "volanti" intendo, di fatto, tutte quelle 
variabili che mi potevano essere utili nel corso della applicazione. Non 
solo, se in qualsiasi momento avevo bisogno di un nuovo parametro lo 
scrivevo in tabella e non dovevo fare altro che usarlo nella 
applicazione senza particolari problemi.
Riguardo al codice fiscale forse dovrebbe esserci in giro anche qualcosa 
che ho scritto. Era sul sito di Baraldi (defunto,il sito intendo,  ma 
ora in carico ad accessgroup se non ricordo male)
Nelle ultime versioni tutta sta roba la facevo con una classe sola 
"autonomamente" auto ricorsiva usando le collezioni e la loro 
caratteristica di poter essere accedute (cavolo mi sono scordato il 
termine) via chiave "parlante"


 
"Bruno Campanini"

Guarda che stai rispondendo a una considerazione di Radicale001, il mio post 
consisteva in due semplici domande.
 
Saluti.
 
 
 
 
 

 l'applicazione prima di scriverla.
 
 
Oddio, l'applicazione va sempre /pensata/ prima di scriverla, comunque tu la 
scriva.
 
Saluti. 
 
 

 scriva.
 
/andrebbe sempre/ pensata prima. Sara' per questo che ho visto un sacco 
di gente pigiare tasti come zombies (me compreso) e poi stupirsi che, al 
primo stormir di fronde, l'applicazione /non/ funziona.



 
Errori tipici di chi è alle prime armi.
Poi o si impara o si cambia lavoro, indipendentemente dalle classi.
 
Saluti. 
 
 

 termine) via chiave "parlante"
 
Si ho capito,
pero' in teoria i dati di una classe dovrebbero essere accedibili 
solo dalla classe. E se questi dati (che servono alla classe) sono
in un DB, anzi DEBBONO ESSERE un DB (ipotesi) ecco che la  classe 
cessa di essere indipendente dall' esterno. L' autocontenimento e 
la trasportabilita' connessa vanno a farsi benedire. Oltre al fatto
che il DB e' accedibile non solo dalla classe. E con questo va a 
farsi benedire anche l' incapsulamento. 
 
 
 

 stormir di fronde, l'applicazione /non/ funziona.
 
Al primo stormir di fronde l'applicazione non funziona mai
come dovrebbe.
Quanto al pensarla prima... conta poi tanto?
È in corso d'opera che si raggiunge la sublimazione
del layout.
Parlo per me naturalmente.
 
Bruno


 
Anche io.
Di fatto stai parlando di un sistema chiuso ed isolato.
Non sta scritto, comunque, da nessuna parte che i dati debbano stare su 
un db. A questo, per il tipo di classe che hai descritto, puoi sopperire 
solo con i dati confinati in quel tipo di classe. Dal punto di vista 
teorico e' ammissibile no?
E comunque l'errore fondamentale mi sembra sia che i dati, nel caso da 
te descritto,  /non/ sono /proprieta'/ (nel senso vero e logico del 
termine) della classe ma posson essere trattati (quindi /metodo/ ) dalla 
classe. Se vuoi essere proprietario di quei dati non devi far altro che 
chiamare la tua classe DBMS che ti fornira' i /metodi/ per accedre ai 
suoi dati ( /proprieta'/ ).


 dati ( /proprieta'/ ).
 
Si, ho capito. Ti ringrazio Maestro. 
 
 
 


Potremmo fare una cosa semplice, semplice (a parte che access gia' la 
da,mi sembra) riscrivere la classe recordset per i files sequenziali?
Tu nel tuo modo io nel mio. Il test sarebbe poi gestire n files 
contemporaneamente.


 Si, ho capito. Ti ringrazio Maestro.
 
Anche io per la deliziosa presa per i fondelli.  ;-)


 contemporaneamente.
 
Prima dovresti spiegarmi che cosa intendi con:
"riscrivere la classe recordset per i files sequenziali"
 
To sei lo mio maestro e il mio autore,
    tu sei solo colui da cui io tolsi
    lo bello stilo che m'ha fatto onore.
 
Bruno


Il concetto è che se ragioni in termini di OOP devi creare dei
livelli/layer separati
Ci sarà un livello, classi che parlano il DB.
Poi un altro livello che gestice la parte logica o business.
Infine un altro livello che gestisce la parte client ( web, vb, ecc
ecc)
Cerca architettura OOP three layer.
 
 

 Anche io per la deliziosa presa per i fondelli.  ;-)
 
No attenzione scusa : dicevo sul serio. Ho capito  davvero dove
sbagliavo. Confondevo le proprieta' della classe con i dati che
eventualmente gli si richiede di gestire. 
 
Adesso grazie a te mi e' tutto chiaro invece.

 Cerca architettura OOP three layer.
 
Finalmente sento cose sensate...!
L'architettura OOP poggia sul concetto di DAL quando si interfaccia con i DB.
Il "DAL" è proprio il Data Access Layer... che svincola il DB dall'interfaccia e rende disponibili i dati, è una sorta di interprete.
 
Purtroppo questi concetti con Access sono molto complessi e decisamente poco applicabili con il VBA anche dovuto alla limitazione del VBA stesso, nonchè dei metodi standard di sviluppo.
 
Non mi unisco alla discussione in quanto come spesso accade ho poi poco tempo per portare a termine ragionamenti complicati.
 
@Alex

 poco tempo per portare a termine ragionamenti complicati.
 
Peccato
 
 

 Il "DAL" è proprio il Data Access Layer... che svincola il DB dall'interfaccia e rende disponibili i dati, è una sorta di interprete.
 
Aria fritta direbbe Bruno Campanini  ;-)
e i "three layers", senza questo nome pomposo, gia' venivano applicati 
al tempo che il comandamento base era "programmazione strutturata":
1) Sezione di I/O dati
2) Sezione di logica
3) Sezione di presentazione (I/O di interfaccia utente)
Il punto di forza dei tanti RAD era in funzione di come trattavano i 
punti 1 e 3 (che, a mio modesto parere, continua ad essere il punto di 
forza di access, classi o non classi) ed il quesito iniziale dell'OP mi 
sembrava piu' "astratto" della banale assegnazione logica di una classe 
a una sezione o ad un'altra o di come le classi vengano implementate in 
Access (la mancanza di alcune "features" probabilmente la conosciamo 
entrambi)


 Aria fritta direbbe Bruno Campanini  ;-)
 
Direi proprio così...
 
Divertitevi!
 
Bruno

 mancanza di alcune "features" probabilmente la conosciamo entrambi)
 
Si, in effetti era piu' "concettuale" ma si basava su una confusione
(come  gia' t' ho scritto qui)  tra  dati che fungono da *proprieta'* 
della classe e dati che la classe e' chiamata eventualmente a gestire.
 
Adesso pero' ho capito, e credo anche bene : la distinzione tra dati
*interni* alla classe ed *esterni* e' parzialmente convenzionale nel
senso che tutto sommato  dipende dal grado di isolamento che si vuol 
conferire alla classe. 
 
Fammi sapere
 
 

 funzionamento interno di Access ?
 
Cercando di "automatizzare" le funzioni di lettura/scrittura sulle 
periferiche di interfaccia (storage,Video,Stampante). Fatto sta che 
tanti "vecchi" sistemi avevano un loro "dizionario" (da qualche parte le 
informazioni devono essere registrate) . Tutti i frameworks per Java 
fanno questo (quelli che conoscevo ;-) ) utilizzando, ora, quella 
struttura dati gerarchica che e' l'XML (e l'HTML).
 
Non e' tanto funzionamento interno e', banalmente, il funzionamento.
Pensa semplicemente all'oggetto form/report.
L'oggetto form/report si occupa della presentazione ma ha al suo interno 
anche l'oggetto di interfaccia per l' I/O dati. In questo senso non c'e' 
molta "indipendenza" tra "layer di presentazione" e "layer dati" ma, 
talvolta, tra la teoria e la pratica c'e' qualche "contaminazione"
 
Trovare informazioni sul funzionamento interno di alcuni "tools" e' roba 
veramente complicata. Per un po' di tempo ci sono stati ottimi libri 
tipo il Developer's Handbook per Access (sono fermo al 2000) ma ormai e' 
un po' di tempo che non seguo piu' la "letteratura" informatica, ho 
cambiato mestiere (sono diventato un "matematico" che "conta", do you 
know?, anche se ho qualche detrattore  ;-)))))))))))))))))   )
 
P.S. Quando sento parlare di "businness" (due n) mi imbufalisco ;-))))
