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).