Appunti di informatica

Introduzione I behavioral patterns sono design patterns che si focalizzano su come gli oggetti di un sistema comunicano tra loro e svolgono le proprie funzioni. Si suddividono principalmente in Class Behavioral patterns, che usano l'ereditarietà per distribuire le funzioni alle varie sottoclassi,  ed i Behavioral Object patterns, che invece usano la composizione. Nel secondo caso ci un oggetto conterrà i riferimenti a uno o più (eventualmente tutti) gli altri oggetti con cui collabora.  Ne esamineremo i principali riassumendone le caratteristiche ed il funzionamento. Chain of Responsibility E' un   Behavioral Object pattern e riguarda la possibilità di inviare dei comandi ad un oggetto ma dando la possibilità di "evadere" quei comandi anche ad altri oggetti. In questo schema abbiamo in genere una gerarchia di oggetti,  in cui ad un nodo perviene un messaggio, ossia la richiesta di eseguire una certa funzione. Quel nodo potrebbe essere ...

Pattern strutturali Ci sono vari modi conosciuti in letteratura in cui classi o oggetti possono combinarsi per ottenere nuovi oggetti, sia a livello statico/strutturale ossia a inerente le classi, che dinamicamente, a livello di istanza/oggetto. Ne presenterò i principali, sintetizzandone le caratteristiche.   Adapter  Anche detto wrapper , modifica l'interfaccia di una classe per renderla compatibile con l'interfaccia richiesta da un client esistente.  In questo pattern distinguiamo:  un client A, una classe o funzione che  utilizza un servizio avente una certa interfaccia IService una classe di servizi definita da una interfaccia IService un servizio B esistente "da adattare", che espone una interfaccia diversa da IService una classe "Adapter" che espone l'interfaccia IService utilizzando un oggetto di tipo B (in questo caso parliamo di object adapter ) o derivando dalla classe B (in questo caso parliamo di class adapter ) Abbiamo dunque due tipi di ad...

Creational patterns Introduzione I Creational patterns sono un sottoinsieme dei design patterns che si prefigge di consentire il cambio dei tipi concreti utilizzati nelle classi senza bisogno di dover riscriverne il codice.  E' possibile che i tipi effettivi da usare siano stabiliti a design time o dinamicamente a run-time, e in quest'ultimo caso non sarà necessaria una ricompilazione. Quando una classe A crea imperativamente istanze di classi di tipo B, ad esempio per invocarne dei metodi o perché alcuni membri di A sono proprio di tipo B, si crea una dipendenza molto forte di A nei confronti di B, e rende una successiva sostituzione di B con una classe diversa, ad esempio derivata da B, impossibile a meno di cambiare il codice dei metodi di A che creano le istanze di B. Questa dipendenza palesemente viola il principio OCP (open/closed principle), che afferma che le entità dovrebbero essere aperte alle estensioni, ma chiuse alle modifiche, infatti in questo caso non c'è mo...

Design Patterns Introduzione Uno degli strumenti più potenti nella risoluzione di problemi complessi sono i design patterns, ossia delle soluzioni standard a problemi tipici.  I principali design patterns Quando si definisce uno schema di risoluzione e gli si da un nome, si ottengono numerosi vantaggi, tra i quali: riuscire più facilmente ad inserirlo in un contesto di una problematica più ampia, poter comunicare con altri in maniera efficace potendosi riferire ad un concetto condiviso, e non ultimo, avere una freccia in più nella propria faretra di sviluppatore/progettista! E' quindi importante acquisire dimestichezza con un numero più grande possibile di design patterns per poterli utilizzare nella risoluzione di problemi complessi e/o nel migliorare soluzioni esistenti. Un altro vantaggio dei design patterns è che essendo oggetto di letteratura, se ne conoscono ampiamente i vantaggi e gli eventuali svantaggi,  pertanto si sa già in partenza che tipo di risultati si otterran...

Cos'è e perché è importante Come abbiamo visto nell'articolo sull' Inversion of  Control , la dependency injection è una tecnica che si prefigge di rendere indipendenti le classi dagli oggetti che esse utilizzano. In sintesi, seguendo questo principio, un metodo di una classe non dovrebbe mai direttamente creare oggetti di altre classi. Chiamiamo client la classe utilizzatrice e service la classe utilizzata. In questi termini, il motivo per cui la D.I. è importante è rendere possibile il cambio del service senza modificare il codice del client, ed è anche molto utile in fase di unit testing perché diventa facile passare degli stub al client ai fini di testarlo. Inoltre rende possibile la separazione delle funzioni, la leggibilità ed il riutilizzo. Come si implementa Si distinguono, nella D.I., quattro elementi principali: il servizio da usare ( service ) il client che utilizza il servizio l'interfaccia che il servizio espone e che viene usata nel client l'injector,...