Appunti di informatica

Gerarchia La gerarchia è un principio che suggerisce la creazione di una organizzazione gerarchica di classi sulla base della loro generalità, classificazione, sostituibilità. La gerarchia è il modo naturale con cui suddividiamo le entità anche nel mondo naturale. Nel software abbiamo due principali relazioni che si prestano alla istituzione di gerarchie: la relazione "is a" e la relazione "is part of". La relazione "is a" è di tipo strutturale ed è quella che nella programmazione ad oggetti viene implementata con l'ereditarietà.  C'è da dire che il meccanismo di ereditarietà inizialmente concepito nei linguaggi OOP nel tempo ha perso un po' del suo appeal iniziale, ed è stato via via sostituito con la mera esposizione di interfacce, per via della migliore manutenibilità e possibilità di refactoring che queste offrono, tuttavia rimangono in molti ambiti in cui l'ereditarietà è un meccanismo perfettamente valido ed efficace. Linee guida La s...

 Astrazione L'astrazione consente di semplificare le entità attraverso la riduzione dei dettagli non rilevanti e la generalizzazione, operata individuandone le caratteristiche principali. L'astrazione è cruciale nel problem solving per poter decomporre un sistema reale in componenti e stabilire le loro connessioni in modo da poterlo gestire più efficacemente. I principi che dovrebbero guidare la progettazione e l'individuazione delle varie entità per comporre un modello di un sistema sono: Identificare  e definire il contorno di un "oggetto" Gli oggetti del dominio applicativo dovrebbero avere corrispondenza nel suo modello logico o concettuale. E' molto più facile parlare di oggetti che  hanno una corrispondenza nel mondo reale che di oggetti completamente astratti, pensiamo al caso in cui si voglia validare il modello con il cliente, o anche solo parlarne con un collega. Ogni componente  del modello dovrebbe essere un oggetto "completo" di tutte le...

  Modularità In generale, per modularità si intende la misura in cui un sistema può essere decomposto e ricombinato. La modularizzazione è applicata al fine di ridurre la complessità di un sistema decomponendolo in varie parti che presentano relazioni di indipendenza e di interdipendenza. In questa sede parleremo di modularità riferendoci alla decomposizione in classi e non a "moduli" intesi come insiemi di classi. La dipendenza tra classi diverse è identificata dall'accoppiamento tra di esse, mentre la qualità della decomposizione ha come buon indicatore la coesione della classe stessa. Accoppiamento L'accoppiamento misura la dipendenza tra due moduli, e idealmente deve essere minore possibile. Distinguiamo vari livelli di accoppiamento, che elenco dal migliore al peggiore: nessun accoppiamento per dati: lista di parametri passati costituiti da dati semplici, oppure un modulo usa un dato, semplice, prodotto da  un altro modulo per struttura: nell'interfaccia di u...

  Incapsulamento L'incapsulamento è la proprietà che hanno le classi di nascondere i dettagli di una certa funzionalità o servizio ed esporre un'interfaccia che consenta al client di poterla utilizzare ad un maggior livello di astrazione. L'incapsulamento attua il principio dell'information-hiding, che è uno dei principali cardini della programmazione. Affinché questo sia ben progettato, occorre quindi che siano nascosti al client i dettagli implementativi, e che modifiche dell'implementazione non rendano necessarie variazioni dei client. Esamineremo alcuni problemi che si possono presentare sull'incapsulamento e vedremo come risolverli. Insufficiente incapsulamento Avviene quando una classe espone dei dettagli implementativi esponendo uno o più membri, creando quindi un accoppiamento indesiderato che esporrà i client ad un impatto qualora l'implementazione cambi.  Il peggiore dei casi è esporre variabili globali che possono dunque essere modificate da più c...

 Technical debt Il peso del technical debt Introduzione Il mondo è in continua evoluzione e con esso cambiano i requisiti e le funzionalità che si richiedono ai software. La manutenzione del software occupa l'80-90% della vita di un software, a volte anche più.  Le continue modifiche al software deteriorano la qualità del software e il suo technical debt. Questo nome, introdotto da Ward Cunningham, rappresenta il costo aggiuntivo delle manutenzioni successive dovuto a scelte non ottimali effettuate.  Una manutenzione non attenta alla limitazione del technical debt fa si che i costi delle manutenzioni successive aumentino sempre più   sino a quando diventa più economico scrivere un nuovo software che manutenere il vecchio, con costi enormi ove si tratti di software di grande complessità. E' dunque essenziale prendere coscienza dei motivi per cui nasce il technical debt e sia riconoscere le varie forme in cui esso si presenta, al fine di poter sia evitarlo che cor...