Il programmatore con solidi principi

datedomenica 28 giugno 2009 alle 9.35  - posted by Manuel Scapolan in Patterns And Principles

Programmare per alcuni è un'arte, un esercizio di creatività che non può essere limitato da regole e schemi, una definizione però che non tiene conto degli obiettivi che un programmatore deve perseguire nello scrivere "buon codice", ovvero mantenibilità, estendibilità, scalabilità, stabilità, etc. Per raggiungere questi obiettivi e non perdere la bussola dobbiamo avere dei solidi principi:

  • S - Single Responsibility Principle
  • O - Open/Closed Principle
  • L - Liskov Substitution Principle
  • I - Interface Segregation Principle
  • D - Dependency Inversion Principle

Ecco i principi che aiutano il programmatore ad ottenere una "buona" programmazione ad oggetti:

Single Responsibility Principle (SRP)

Ogni classe deve essere disegnata per svolgere bene un solo compito, avere una sola responsabilità, in pratica una classe deve avere un solo motivo per cambiare. Seguire questo principio porta automaticamente ad avere un basso accoppiamento.

Open/Closed Principle (OCP)

Una classe deve essere aperta alle estensioni, ma chiusa alle modifiche. Dobbiamo quindi essere in grado di estendere il comportamento di una classe senza modificarne l'implementazione (aka codice sorgente). Come? Facendo uso di classi astratte o interfacce, ovvero sfruttando il polimorfismo.

Liskov Substitution Principle (LSP)

Una funzione che utilizza un riferimento ad una classe base deve poter utilizzare al suo posto una qualsiasi delle classi derivate senza conoscerne l'implementazione. In pratica non dobbiamo modificare in alcun modo il comportamento di una classe base in una derivata. Una via potrebbe essere preferire dove possibile la composizione all'ereditarietà, ponendosi ogni volta la fatidica domanda IS A or HAS A?

Interface Segregation Principle (ISP)

Una classe non deve implementare una interfaccia che non usa o che usa parzialmente. Molte volte si deve preferire più interfacce con una sola funzionalità ad un'unica interfaccia che fa tutto. Il motivo? Una classe è influenzata dal cambiamento di una interfaccia anche se non la usa.  

Dependency Inversion Principle (DIP)

Si basa sul concetto che una classe di un alto livello non deve dipendere dall'implementazione di classi o entità di un livello inferiore. In pratica per raggiungere tale scopo devo progettare le classi pensando alle interfacce e non alle implementazioni. Questo porta ad avere non solo un basso accoppiamento tra i livelli della mia architettura, ma automaticamente a poter sostituire l'implementazione di un livello inferiore senza pregiudicare il funzionamento di quelli superiori.

 

In conclusione questi principi aiutano il programmatore, laddove non arriva l'esperienza, ad ottenere un codice di qualità che mantenga una forte coesione ed un basso accoppiamento tra le entità del sistema. Non devono però diventare un dogma, ma uno strumento da conoscere e da utilizzare a seconda degli obiettivi e dei requisiti applicativi.

Link utili

Autosave del contenuto di una textarea in un cookie con Yahoo! User Interface Library

dategiovedì 25 giugno 2009 alle 17.37  - posted by Manuel Scapolan in Javascript

Può essere utile avere a disposizione nelle applicazioni web un sistema di salvataggio automatico del testo, vediamo come ottenerlo con l'aiuto della Yahoo! User Interface Library.

Utilizziamo per l'occasione il componente Rich Text Editor e l'utility di gestione dei cookie. Con lo snippet seguente dichiariamo l'editor e poi ne salviamo il testo ad intervalli regolari in un cookie:

var editor1 = new YAHOO.widget.Editor('textarea1', {
   toolbar: {
   titlebar: 'Testo:',
   collapse: true,
   buttons: [
    { group: 'style',
    buttons: [
      { type: 'push', label: 'Grassetto', value: 'bold' },
      { type: 'push', label: 'Corsivo', value: 'italic' },
      { type: 'push', label: 'Sottolineato', value: 'underline' },
      { type: 'push', label: 'Ripristina', value: 'recovery' }]
    }
   ]}
});
var started = false;
editor1.on('editorKeyDown', function(ev) {
   if(!started){
      setInterval("saveContentToCookie()",15000);
      started = true;
   }
  }, this, true);
function saveContentToCookie() {
   if(editor1)
   {
      var content = editor1.getEditorHTML();
      if(content.length > 5){ //comprendo anche il br
         YAHOO.util.Cookie.set("recovery", content, { expires:
          new Date(new Date().getTime() + 2*24*60*60*1000) });
      }
   }
}

Analizziamo il codice passaggio per passaggio: prima creo una istanza del Rich Text Editor di Yahoo! (righe 01-14) poi all'evento KeyDown dell'editor associo un handler che faccia partire ad intervalli regolari la funzione che esegue il salvataggio del testo nel cookie (righe 15-21). Infine nella funzione di salvataggio (righe 22-31) prendo il testo contenuto nell'editor e lo salvo nel cookie attraverso il metodo Cookie.set dell'utility messa a disposizione dall'API Yahoo! YUI.

Per recuperare i dati dal cookie aggiungo un pulsante all'editor (vedi riga 11 snippet precedente) al click del quale visualizzo in un div i dati presenti nel cookie prelevati precedentemente attraverso il metodo Cookie.get.

Ma andiamo con ordine. Prima vediamo la struttura del div utilizzato per visualizzare il contenuto del cookie:

<div id="cookieContent">
<div class="hd">
Contenuto salvato
</div>
<div id="cookieContentBody" class="bd">
<script>
    document.getElementById('cookieContentBody').innerHTML = 
        YAHOO.util.Cookie.get("recovery");
   </script>
</div>
<div class="ft">
   <span style="font-size: 10px; color: #666666">
   (Il testo viene salvato ogni 15 secondi)</span>
</div>
</div>

Il div ha una struttura ben definita che usufruisce degli skin messi a disposizione dall'API di Yahoo! e nel suo corpo accede al DOM per inserire nell'html il contenuto del cookie.

Successivamente da codice javascript istanzio su quel div un oggetto Panel inizialmente non visibile ed al click del pulsante dell'editor definito per l'occasione lo visualizzo attraverso il metodo show():

var cookieContent = new YAHOO.widget.Panel("cookieContent", 
    { xy:[300,220], visible:false, width:"500px" } );
cookieContent.render(); 
 
editor1.on('toolbarLoaded', function() {
   this.toolbar.on('buttonClick', function(o) {
   switch(o.button.value) {
      case 'recovery':
        onRecoveryClick(o, editor1);
          break;
      }
   });
 }, editor1, true);
var onRecoveryClick = function (e, obj) {
   cookieContent.show();
};

Per rendere del tutto user-friendly il recupero dei dati salvati ho aggiunto una funzione che chiamata da un pulsante all'interno del Panel consente di incollare il contenuto del cookie direttamente nell'area di testo dell'editor:

function pasteContentFromCookie() {
   if(editorRisposta){
      editorRisposta.setEditorHTML(YAHOO.util.Cookie.get("recovery"));
   }
   cookieContent.hide();
}

In conclusione aggiungo che per far funzionare il tutto è necessario linkare nell'head i file sorgenti della libreria Yahoo! YUI e precisamente:

<script src="/yahoo-min.js" type="text/javascript"></script>
<script src="/cookie-min.js" type="text/javascript"></script>
<script src="/element-min.js" type="text/javascript"></script>
<script src="/container-min.js" type="text/javascript"></script>
<script src="/button-min.js" type="text/javascript"></script>
<script src="/editor-min.js" type="text/javascript"></script>

E questo è davvero tutto!

tagsTags: ,

DataGridView e TableAdapter: Update in-line e Performance Tip

datemercoledì 24 giugno 2009 alle 22.08  - posted by Manuel Scapolan in Tips and Tricks

Se dobbiamo sviluppare applicazioni Windows Form "quick and dirty" su basi di dati non troppo complesse, niente ereditarietà o self-relationship per intenderci, con il DataSet ed i TableAdapter possiamo soddisfare le nostre esigenze con un po' di drag and drop ed alcuni click del mouse.

Update in-line

Tutto bello se non fosse che per quello che non ci viene dato in automatico dobbiamo sudare le famose 7 camicie. Mi è capitato recentemente di dover applicare ad una DataGridView collegata ad un DataSet la modifica in-line, ovvero il salvataggio dei dati all'uscita dalla cella. Dopo innumerevoli tentativi sono giunto alla seguente conclusione:

private void dataGridView1_CellValueChanged
   (object sender, DataGridViewCellEventArgs e)
{
   this.dataGridView1.EndEdit();
   this.customersBindingSource.EndEdit();
   if (this.dataSet1.HasChanges(DataRowState.Modified))
   {
      this.customersTableAdapter.Update(this.dataSet1.Customers);
   }
}

In pratica nell'handler dell'evento CellValueChanged del DataGridView procedo alla chiamata dei metodi EndEdit rispettivamente sulla DataGridView e sul BindingSource collegato in modo da propagare la modifica alla sorgente dati bindata alla griglia. Successivamente controllo se ci sono modifiche (può essere omesso visto lo scopo dell'evento scatenato) ed a quel punto chiamo il metodo Update del TableAdapter che procede alla persistenza dei dati sullo storage.

Performance tip

Lavorando con un insieme maggiore di record il TableAdapter soffre di un po' di lentezza se gli passiamo nel metodo Update tutta la tabella. Per migliorare le performance possiamo utilizzare direttamente il DataAdapter, accessibile tramite la proprietà Adapter, al quale passiamo un dataset con le modifiche da persistere, ecco come fare:

private void dataGridView1_CellValueChanged
   (object sender, DataGridViewCellEventArgs e)
   this.dataGridView1.EndEdit();
   this.customersBindingSource.EndEdit();
   if (this.dataSet1.HasChanges(DataRowState.Modified))
   {
      DataSet ds = this.dataSet1.GetChanges(DataRowState.Modified);
      this.customersTableAdapter.Adapter.Update(ds);
   }
}

Quando si lavora con il DataSet devono essere gestite opportunamente concorrenza e caricamento dei dati in modo da evitare perdita di informazioni ed un utilizzo pesante delle risorse. Nel primo caso la gestione viene definita tramite opportuna configurazione del TableAdapter, nel secondo caso è compito nostro implementare dei meccanismi di paginazione dei dati, ma questa è un'altra storia...

Aprire un pdf in una determinata pagina

datedomenica 7 giugno 2009 alle 18.36  - posted by Manuel Scapolan in Tips and Tricks

Può succedere a volte di voler linkare un argomento all'interno di un documento pdf. Se il documento ha molte pagine diventa difficile per l'utente trovare da solo le informazioni necessarie. Per questo motivo può essere utile aprire il documento nella pagina che contiene l'argomento interessato.
Per aprire un documento pdf in una determinata pagina dobbiamo aggiungere dopo il nome del file la stringa #page= seguita dal numero della pagina.
Ad esempio:

> HQL: The Hibernate Query Language

Con questo link siamo in grado di aprire la documentazione di NHibernate direttamente nel capitolo che parla del linguaggio HQL.

tagsTags:

About me

manuel scapolanSono un consulente informatico. Nel 2004 terminati gli studi in Ingegneria Informatica (1° livello), ho iniziato come freelance collaborando con una ditta di consulenza informatica ed una agenzia di marketing e comunicazione nello sviluppo di applicazioni web. Attualmente divido il lavoro di sviluppatore e progettista web con attività di formazione nel settore della programmazione.
View Manuel Scapolan's profile on LinkedIn

Follow me on Follow manuelscapolan on Twitter

Calendario


<<  agosto 2010  >>
lumamegivesado
2627282930311
2345678
9101112131415
16171819202122
23242526272829
303112345

Disclaimer

Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati mediante:
creative commons
Attribuzione: Non commerciale
Condividi allo stesso modo. R.2.5

Books (a bit more about my library)

Domain Driven Design - Eric Evans Applying Domain-Driven Design and Patterns - Jimmy Nilsson Refactoring to Patterns - Joshua Kerievsky Design Patterns -  Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides Code Complete Second Edition - Steve McConnell Patterns of Enterprise Application Architecture - Martin Fowler Agile Principles, Patterns, and Practices in C# - Robert C. Martin xUnit Test Patterns - Gerard Meszaros Refactoring - Martin Fowler CLR via C# Second Edition - Jeffrey Richter Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries - Krzysztof Cwalina, Brad Abrams Don't make me think! - Steve Krug Bulletproof Ajax - Jeremy Keith

Manuel Scapolan Copyright © 2007 - 2010 - Tutti i diritti riservati - Powered by BlogEngine.NET 1.5.0.7 - silk icons by famfamfam - Time CET