Classe (informatica)

Una classe, nella programmazione orientata agli oggetti, è un costrutto di un linguaggio di programmazione usato come modello per creare oggetti. Tale modello comprende attributi e metodi che saranno condivisi da tutti gli oggetti creati (istanze) a partire dalla classe. Un oggetto è, di fatto, l'istanza di una classe.

Una classe è identificabile come un tipo di dato astratto che può rappresentare una persona, un luogo oppure una cosa, ed è quindi l'astrazione di un concetto, implementata in un software. Fondamentalmente, essa definisce al proprio interno lo stato, i cui dati sono memorizzati nelle cosiddette variabili membro o attributi, e il comportamento dell'entità di cui è rappresentazione, descritto da blocchi di codice riutilizzabili chiamati metodi.

Nell'analisi object-oriented

Il termine classe può indicare, a seconda del contesto, una categoria di oggetti, un tipo di dati, o l'implementazione di un tipo di dati. Queste tre accezioni si trovano rispettivamente (soprattutto) nell'analisi orientata agli oggetti, nella progettazione orientata agli oggetti e nei linguaggi di programmazione orientati agli oggetti.

L'analisi dei requisiti, o semplicemente analisi, costituisce una delle prime fasi del ciclo di vita del software, e precede almeno le fasi di progettazione e implementazione. Lo scopo di questa fase è comprendere, chiarire e documentare cosa il sistema software deve fare, ovvero quali sono le funzionalità che si richiede possieda; non ci si occupa invece di definire come siano realizzate queste funzionalità (se non, a un livello molto grossolano, per una stima approssimativa dei costi).

Si parla di analisi object-oriented se tale fase viene condotta utilizzando tecniche che si basano su un metamodello object-oriented ovvero, detto più semplicemente, se l'analisi fa uso degli strumenti concettuali propri delle tecnologie orientate agli oggetti, primo fra tutti il concetto di "classe".

Nell'analisi object-oriented si possono distinguere due sotto-attività: l'analisi del dominio e l'analisi dei requisiti propriamente detta. L'analisi del dominio consiste nel chiarire innanzitutto quali sono i concetti importanti che il sistema da sviluppare dovrà trattare, e nel precisare il più dettagliatamente possibile il significato di questi concetti e le relazioni che li legano l'uno all'altro.

Per esempio, durante la fase di analisi per un sistema software nel dominio bancario occorrerà investigare a fondo come funziona un conto corrente, quali relazioni possono legare diversi conti, i conti alle filiali, le filiali ai clienti, e così via. Successivamente alla caratterizzazione precisa delle entità facenti parte del dominio si procederà a stendere i requisiti veri e propri del sistema, ovvero descrivere come il sistema si inserisce nel dominio e interagisce con esso.

Nell'analisi object-oriented la classe è il concetto fondamentale utilizzato per descrivere le entità del dominio. Una classe rappresenta una categoria di entità (per esempio, i conti correnti) in termini di due aspetti:

lo stato delle entità di quella categoria, descritto in termini di un insieme di attributi che possono variare nel tempo; per esempio, ogni conto corrente ha un saldo che varia nel tempo;

il comportamento di quelle entità, in termini delle operazioni che tali entità possono eseguire o che possono essere eseguite su di esse; per esempio, da un conto corrente si può prelevare denaro. Le operazioni vengono analizzate stabilendo (anche) in quale modo la loro applicazione modifica lo stato (il prelievo di denaro diminuisce l'entità del saldo).

Le singole entità vengono dette istanze (ovvero esempi, casi particolari) della loro classe di appartenenza. Così, il mio conto corrente è un'istanza della classe conto corrente.

Il modello del dominio che l'analisi va a definire può essere arricchito da una serie di informazioni aggiuntive che riguardano le relazioni fra le diverse classi identificate. Fra gli esempi solitamente più importanti di relazione si possono citare i seguenti:

le associazioni specificano relazioni fra le istanze delle classi; per esempio, il fatto che i conti correnti siano intestati a clienti della banca definisce un'associazione fra la classe conto corrente e la classe cliente;

le aggregazioni sono un tipo particolare di associazione che ha luogo quando le istanze di una classe devono considerarsi parti di istanze di altre classi; per esempio, un'istanza della classe automobile comprende come proprie parti istanze delle classi ruota, pistone, parabrezza e via dicendo. Il confine fra associazioni generiche e aggregazioni non è sempre netto.

le relazioni ISA (relazione "è un") specificano che una classe deve considerarsi una sottocategoria o sottoclasse di un'altra (detta superclasse); per esempio, la classe conto corrente potrebbe essere descritta come sottocategoria della classe servizio bancario. Il nome della relazione segue dal fatto che si può sensatamente dire, per esempio, che un conto corrente è un ("is a", ISA) servizio bancario. Si noti che questa rappresenta una relazione esclusivamente fra classi e non fra istanze. La relazione ISA ha un ruolo importante nella razionalizzazione di un modello. Un aspetto fondamentale è che si può assumere che una sottoclasse sia sicuramente dotata di tutti gli attributi, le operazioni e le associazioni della superclasse; eventualmente può averne altre, legate alle particolarità specifiche della sottocategoria di oggetti che descrive. Per esempio, se un servizio bancario ha un costo annuo ed è intestato a un cliente, tutto ciò resta vero per un conto corrente; quest'ultimo ha inoltre un saldo, attributo che non ha necessariamente senso per tutti i servizi bancari (e che quindi non comparirà nella classe più generica servizio bancario).