Frage an die Informatiker..

[DeCaY4]

(abstrakte) Datentypen

.. oder alle die es werden wollen.

Ich hab da einige Verständnisschwierigkeiten mit Datentypen/abstrakten Datentypen.
Ich arbeite grad mit dem Ottmann/Widmayer und finde die Erklärungen irgendwie widersprüchlich, wikipedia hilft mir auch nur begrenzt weiter.

So wie ich das sehe, hat man Mengen, die einen bestimmten Wertebreich haben (nat. zahlen, ganze Zahlen..) als (Grund-)Datentypen in praktisch allen Programmiersprachen implementiert (int, double, character....).

Abstrakte Datentypen wären für mich sowas wie Klassen in Java oder typedef_struct Konstrukte in C, halt eine Zusammenfassung von verschiedenen Mengen und damit verschieden (Grund-)datentypen.

Zu beiden gehören noch verschiedene Operationen (Addition, Multiplikation... einerseits, create, edit... andererseits).

Datenstrukturen wären dann für mich implementierte abstrakte Datentypen.

Allerdings tun sich mir da verschiedene Fragen auf..
1. wo würde man Strings und arrays einordnen? arrays sind ja im Grunde Matrizen aus der Mathematik; ein String ist (z.B. in C) ein characterarray. Wäre ein array eine Datenstruktur, ein Datentyp oder ein abstrakter Datentyp?
2. Graphen sind ja abstrakte Datentypen; Bäume sind spezielle Graphen; allerdings kann man Bäume auch als spezielle lin.Listen auffassen; ist ein Baum also ein Mischung aus Graph/lin.Liste?
3. im Ottmann/Widmayer werden Mengen als eigene abs. Datentypen aufgefasst. Mengen sind (für mich) aber der Grundbaustein der Mathematik und axiomatisch definiert, wie passt das zusammen?
4. Java-spezifisch: man kann ja wohl sagen, dass jede abstrakte Klasse einem abstrakten Datentyp entspricht. Was ist mit normalen Klassen/Interfaces? Die (Grund-)datentypen int, double.. sind ja z.B. in den Wrapperklassen wie normale Klassen definiert. Wäre dann also jede Klasse ein Datentyp?

thx for help.

e: mein Assistent meinte, ich sollte evtl den thread Titel ändern.. ursprünglich war das Ding ja auch im Com..

 

[swallie]

das ist eine programmierfrage die du hast. ich kann dir da nicht helfen ausser den hinweis zu geben, dass dein topic nicht grade aussagekräftig ist und du deshalb auch nicht die menge an replay erwarten darfst

 

[The_Company]

Quote Wikipedia:
"Abstrakter Datentyp (ADT) ist eine Bezeichnung in der Informatik für Datentypen, um diese unabhängig von einer konkreten Implementierung zu spezifizieren."

Ergo ist die Java-Klasse String ein Datentyp, der den abstrakten Datentyp String implementiert, genau so wie der C-String (das Char-Array) auch ein Datentyp ist, der den abstrakten Datentyp String implementiert.


und nochmal Wikipedia:
"Wird der Schwerpunkt der Betrachtung auf die konkrete Implementation der Operationen verschoben, so wird anstelle des Begriffs Datenstruktur auch häufig von einem Abstrakten Datentypen gesprochen. Der Übergang von der Datenstruktur zu einem Abstrakten Datentyp ist dabei nicht klar definiert, sondern hängt einzig von der Betrachtungsweise ab."

eine Datenstruktur ist also ein abstrakter Datentyp mit einer bestimmten Struktur bei der Datenhandhabung, Beispiele also Liste oder Array (die ja zB verschiedene Zeit-Charakteristika beim Zugriff auf Elemente, append oder prepend Operationen haben).


Nachdem denn nun klar ist, was diese beiden Begriffe bedeuten, ergibt sich daraus für Deine Fragen:
1. Arrays sind abstrakte Datentypen und Datenstrukturen. Eine bestimmte implementierung eines Arrays (java.util.Vector oder C-Arrays) sind Datenstrukturen. Genauso für Strings.
2. Die Datenstruktur Baum ist eine lin. Liste oder ein Graph, je nach Implementierungsdetail. Der abstrakte Datentyp Baum ist wahrscheinlich weder/noch, bei ner Datenstruktur wärs dann entweder/oder.
3. Mathematik und Informatik haben mal gar nichts miteinander zu tun. Da Computer nicht mit Mengen, sondern mit Bits rechnen, musst Du die Menge an sich als abstrakten Datentypen einführen.
4. Klassen sind auf jeden Fall Datentypen. Interfaces würde man in Lehrbüchern wahrscheinlich als abstrakte Datentypen einführen. Schliesslich sind sie "unabhängig von einer konkreten Implementierung".


Scheiss Fachwortverbiegung da

 

[DeCaY4]

Oho, hat ja doch noch wer geantwortet.. ^^
offenbar ist die Grenze zwischen den Begriffen "Abstrakter Datentyp" und "Datenstruktur" fließend (thx ^^). Auch wenn ich sowas hasse, drauf geschissen, ich weiß ja jetzt ungefähr, was was ist. ;D

Allerdings verstehe ich noch nicht, wann ich einen ADT in Java als abstrakte Klasse und wann als Interface implementieren müsste. Ich hab noch nicht viel Erfahrung mit Java, und der Unterschied zwischen abstrakten Klassen und Interfaces ist in meinen Augen marginal.
Ergo frage ich mich z.B., ob ich einen Baum als Interface implementieren soll (wo nur gesagt wird, dass es die Methoden einfügen, suchen etc. gibt, egal ob in den Knoten Integer, Strings o.ä. stehen) oder als abstrakte Klasse, von der ich dann nen AVL Baum, B-Baum etc ableite.

 

[Sas~iN~LoVe]

Naja, wenn du irgendwelche Methoden gleich für alle deine Bäume nutzen kannst, wäre die abstrakte Klasse sinnvoller (weil diese Methode dann eben nicht abstrakt ist und schon implementiert werden kann), sonst nimmste halt n Interface.

Das Interface ist einfach ein Spezialfall der abstrakten Klasse, gibts auch nicht in jeder OO-Sprache (Smalltalk z.B. kennt keins, wenn ich mich recht erinnere).

 

[The_Company]

Ein abstrakter Datentyp wird durch eine Implementation zu einem (konkreten) Datentyp. Datentypen werden also immer durch eine Klasse repräsentiert.

Ein Interface ist eine Schnittstelle, die die Interaktion zwischen verschiedenen Komponenten beschreibt. Was das genau heisst, hab ich aber auch erst richtig begriffen, als ich mit Swing angefangen habe.

Eine abstrakte Klasse ist eine Klasse, die nicht vollständig implementiert ist. Das ist meistens dann der Fall, wenn Unterklassen davon diese Funktionalität unterschiedlich implementieren, das Vorhandensein der Funktionalität aber schon jetzt gebraucht wird. Das klingt kompliziert und ist es auch, denn man braucht es wirklich selten. Beispiele davon im Programmierunterricht sind deshalb meistens sehr konstruiert.