Un link da annotare tra quelli da controllare giornalmente:
http://blogs.ugidotnet.org/
Wednesday, December 13, 2006
Tuesday, December 05, 2006
Interfacce, Garbage collection e COM
Leggendo un capitolo gratuito su Delphi per .NET di Marco Cantù dove vengono analizzate le modifiche effetuate al linguaggio per adattarlo a .NET, ho riflettuto su un passaggio lì riportato riguardante le interfacce. In pratica e finalmente il concetto di Interfaccia si sgancia da COM: non è più necessario associare ad un interfaccia un GUID.
Il passaggio che mi ha interessato di più è quello in cui si fa riferimento al "reference counting".
In pratica se un oggetto espone un interfaccia può essere acceduto da parte di altri oggetti attraverso questa interfaccia. La domanda che sorge spontanea è la seguente: chi distrugge l'oggetto originario?
In un ambiente COM dove non esiste un Garbage collector la cosa viene gestita tramite il meccanismo del conteggio dei riferimenti (reference counting): ogni volta che un oggetto A accede ad un altro B tramite l'interfaccia, B incrementa di uno il numero di riferimenti. Quando l'oggetto A termina di riferire B il numero dei riferimenti è decrementato.
Tutto ciò ha senso se non esiste (come in JAVA e in .NET) un sistema automatico di gestione dei riferimenti che automaticamente distrugge gli oggetti non più riferiti da nessuno.
Per quanto riguarda il reference counting in COM suggerisco quest'altro articolo oltre che l'onnipresente Wikipedia
Il passaggio che mi ha interessato di più è quello in cui si fa riferimento al "reference counting".
In pratica se un oggetto espone un interfaccia può essere acceduto da parte di altri oggetti attraverso questa interfaccia. La domanda che sorge spontanea è la seguente: chi distrugge l'oggetto originario?
In un ambiente COM dove non esiste un Garbage collector la cosa viene gestita tramite il meccanismo del conteggio dei riferimenti (reference counting): ogni volta che un oggetto A accede ad un altro B tramite l'interfaccia, B incrementa di uno il numero di riferimenti. Quando l'oggetto A termina di riferire B il numero dei riferimenti è decrementato.
Tutto ciò ha senso se non esiste (come in JAVA e in .NET) un sistema automatico di gestione dei riferimenti che automaticamente distrugge gli oggetti non più riferiti da nessuno.
Per quanto riguarda il reference counting in COM suggerisco quest'altro articolo oltre che l'onnipresente Wikipedia
ACCESS e le classi
Ho già avuto modo di dire in passato che Access ha una serie di notevoli caratteristiche che lo rendono molto buono per la realizzazione di prototipi.
In questi giorni ho avuto modo di usare Access in maniera molto spinta ed ho dovuto strutturare il codice in modo da renderlo modulare. Poichè non avevo particolare necessità di creare Oggetti a runtime ho pensato di poter risolvere la cosa con le classi statiche. Questo purtoppo non può essere fatto poichè mancano sia metodi che campi statici (nel senso "vero" del termine). Quindi dopo qualche test ho optato per una strutturazione del codice tramite l'uso dei moduli (non di classe). In pratica questi moduli si comportano a tutti gli effetti come classi statiche ed anche il meccanismo di chiamata con i punti di separazione modulo.funzione o modulo.campo rende il codice molto leggibile.
In questi giorni ho avuto modo di usare Access in maniera molto spinta ed ho dovuto strutturare il codice in modo da renderlo modulare. Poichè non avevo particolare necessità di creare Oggetti a runtime ho pensato di poter risolvere la cosa con le classi statiche. Questo purtoppo non può essere fatto poichè mancano sia metodi che campi statici (nel senso "vero" del termine). Quindi dopo qualche test ho optato per una strutturazione del codice tramite l'uso dei moduli (non di classe). In pratica questi moduli si comportano a tutti gli effetti come classi statiche ed anche il meccanismo di chiamata con i punti di separazione modulo.funzione o modulo.campo rende il codice molto leggibile.
Subscribe to:
Posts (Atom)