[OT] ADT (Abstract Data Type)

[keratox]

Discutiamo su .... tipi di dati astratti.
In due testi, il primo sulla OOP, il secondo sull'ingegneria del software, vengono definiti gli ADT (tipi di dati astratti) come un insieme di dati e operazioni ad essi applicabili.

Wikipedia dice

tipo di dato astratto o ADT (Abstract Data Type) è un tipo di dato le cui istanze possono essere manipolate con modalità che dipendono esclusivamente dalla semantica del dato e non dalla sua implementazione.

Ma cosa vuol dire?

Questi ADT (in java), si creano mediante interfacce (public interface ...) o classi?

Inoltre, stando alla prima definizione: tutto è poco chiaro.

Insieme di dati. Sono intese forse variabili e altri oggetti?

operazioni ad essi applicabili. Metodi?


I tipi di dati astratti stanno alla base dell'incapsulamento, poichè permettono di nascondere i dettagli dell'implementazione e di favorire il riutilizzo (poichè appunto si ricorre all'astrazione individuando soluzioni generali e semplificate di problemi complessi).


La mancanza di esempi pratici forse causa incomprensioni.
Qual è un ADT? Il primo listato che segue, o il secondo, o entrambi?

public interface Animale{
   public void cammina();
   public void mangia();
}

public class Animale{
   String specie;
   String nome;

   public Animale(String nome, String specie){
      this.nome=nome;
      this.specie=specie;
   }

   public void cammina(){

   }

}

Ovviamente l'interfaccia (dal punto di vista di codifica) in sè non è nulla.

Dunque...
Qualcuno mi sa dare una definizione esaustiva degli ADT (so che chiedo troppo )
Come si definisce un tipo di dato astratto?

[unomichisiada]

Io preferisco la definizione data da wikipedia mentre quella dei due libri la vedo più confacente a un Oggetto.La def di Wikipedia pone giustamente l'accento sul fatto che la definizione di un ADT si mantiene indipendentente dall'implementazione.Per fare un esempio banale che può però aiutare a comprendere, una coda con priorità è un ADT (un tipo di dato astratto appunto) definito come un insieme non meglio specificato di elementi, tutti dello stesso tipo per il quale esiste la proprietà che in ogni momento l'elemento top sia il più "grande" e per il quale (insieme) sono definite le tre operazioni di inserimento, estrazione dell'elemento top e check sul fatto che la coda non sia vuota (oltre all'operazione di creazione di una coda vuota ovviamente),che preservano tutte la proprietà dell'ADT in questione. Ora questo ADT si può implementare in svariati modi servendosi di altri ADT,che possono essere ad esempio uno heap (molto usato) o una lista concatenata. Da notare che si può scendere ad un livello ancora più basso parlando dell'implementazione in termini di puntatori, allocazione dinamica o array e allocazione statica. A mio avviso è un errore cercare di identificare in qualche modo dei costrutti propri del liguaggio java (e più in generale dell'OOP) quali classi o interfacce con gli ADT.Gli ADT esistono a prescindere dall'OOP e si possono implementare anche in C ad esempio che con l'OOP non c'entra nulla.

[unomichisiada]

I tipi di dati astratti stanno alla base dell'incapsulamento, poichè permettono di nascondere i dettagli dell'implementazione e di favorire il riutilizzo (poichè appunto si ricorre all'astrazione individuando soluzioni generali e semplificate di problemi complessi).

In definitiva questa frase è errata secondo me!Non credo tu l'abbia estrapolata da alcun libro, penso sia solo una tua deduzione

[keratox]

Si', di fatto non è una definizione propria di un libro. Però, riassumendo, mi sembrava pertinente al testo.

Quindi, da quello che hai detto posso dedurre che...
gli ADT sono più facilmente realizzabili attraverso classi, perchè così si definiscono entità indipendenti (a cui...=> definizione).
Poco più difficile ma possibile, nella programmazione modulare.
Decisamente difficile, nella programmazione procedurale, impossibile in programmi complessi con quest'ultimo stile.

Erro?

[unomichisiada]

Originariamente inviato da keratox
Si', di fatto non è una definizione propria di un libro. Però, riassumendo, mi sembrava pertinente al testo.

Quindi, da quello che hai detto posso dedurre che...
gli ADT sono più facilmente realizzabili attraverso classi, perchè così si definiscono entità indipendenti (a cui...=> definizione).
Poco più difficile ma possibile, nella programmazione modulare.
Decisamente difficile, nella programmazione procedurale, impossibile in programmi complessi con quest'ultimo stile.

Erro?

Se vogliamo...diciamo che ti posso dar ragiore in queste tue deduzioni nel sesno che tu nell'implemnetare un qualsivoglia ADT devi garantire che la/le sua/e proprietà sia/siano conservata/e e un linguaggio ad oggetti sicuramente ti agevola in questo perchè offre dei costrutti apposta per rendere concreta una entità che altrimenti sarebbe solo concettuale.Per fare sempre un esempio quando in C devi implementare l'ADT lista concatenata puoi solo scrivere una o più strutture nodo ed una o più funzioni che solo concettualmente sono pensabili come facenti parte della stessa entità (l'ADT che stai implementando), mentre in java o c++ (ad esempio) è possibile utilizzare costrutti del linguaggio per individuare in maniera più ,marcata e concreta questa distinzione col resto del programma.Torno a ripetere però che ciò gli ADT non sono necessaiamente legati all'OOP,puoi benissimo farne a meno a patto che nel programmarne uno ti imponi di rispettare la sua interfaccia (intesa in senso lato non come il costrutto di alcuni linguaggi OOP).

[keratox]

Ok.

Però è ancora poco chiaro cosa sia un ADT.

1 )Cambiamo procedimento di analisi. Proviamo a dire cosa non è....


2 ) Domanda specifica. In c/c++ una struttura può essere un tipo di dato astratto?

struct mystruct{
   int val;
   mystruct *next;
   mystruct *previous;
}

Il fatto che si tratti di un ADT dipende dalla sua implementazione (in riferimento all'interfaccia) o dall'approccio con cui si utilizza?

[keratox]

Qui http://remus.rutgers.edu/cs314/f2005...pic06_adts.pdf
viene detto

Astrazione dati : meccanismo che incapsula o nasconde la rappresentazione e i dettagli delle operazioni di un tipo di dato dai suoi utenti.
Ogni accesso è attraverso un'interfaccia definita.

Provo a fare un esempio

public class Employee{
   String name;
   String surname;
   int age;

   public Employee(String name, String surname, String age){
       this.name=name;
       this.surname=surname;
       this.age=age;
   }
   
   public int getAge(){
      return age;
   }

   public String getName(){
      return name + " " + surname;
   } 

}

Questa classe è un ADT o solo un corretto uso dell'incapsulamento???

Cosa dovrei "fare" per far si che l'esempio precedente non sia un tipo di dato astratto?

[unomichisiada]

Originariamente inviato da keratox
Qui http://remus.rutgers.edu/cs314/f2005...pic06_adts.pdf
viene detto




Provo a fare un esempio

public class Employee{
   String name;
   String surname;
   int age;

   public Employee(String name, String surname, String age){
       this.name=name;
       this.surname=surname;
       this.age=age;
   }
   
   public int getAge(){
      return age;
   }

   public String getName(){
      return name + " " + surname;
   } 

}

Questa classe è un ADT o solo un corretto uso dell'incapsulamento???

Cosa dovrei "fare" per far si che l'esempio precedente non sia un tipo di dato astratto?

A parte il fatto che un po mi sfugge il perchè ti crucci tanto su questo problema (che invece lascia la mia esistenza del tutto tranquilla...),non ho molto altro da aggiungere a quello che già ho detto.Gli ADT si possono avvalere nella loro implementazione di incapsulamento e concetti che gli ruotano attorno (classi,oggetti, interfacce) ma non sono la stessa cosa.Si tratta solo di specifiche che definiscono delle strutture dati astratte appunto,niente di più e niente di meno. L'array,lo stack,la coda,la lista,albero...sono tutti ADT, e se noti hanno tutti la caratteristiche di essere costituiti da un INSIEME di elementi organizzato secondo le specifiche dell'ADT stesso.Non credo abbia ne un senso ne un'utilità cercare di determinare se una classe del genere, che non ha questa caratteristica sia o meno un ADT.