Abstract Data Type in Java

I was given a D- and told I was way off.

He is right

I read the article posted above, and I wouldn't have given you a D-. I think this is more a case of trying to figure out what the teacher wants than trying to argue why you're "right." Those kinds of things always made me very angry, and when I was in college, I would have dropped the class. I really don't think it is the right thing to do, but I have never been very go at doing the right when thing when dealing with people.

I don't see anything wrong with your answer, except that, because of the D-, it wasn't the same as the guys definition.

"May the semicolons be ever in you favor."

My problem with your definition is that you've described a concrete data type, not an abstract data type. An abstract data type just defines operations. When you start talking about what data it holds and what operations are mutators and accessors then you've got a concrete data type. Think of an abstract data type as the interface, while what you've described is an implementation.

Do you mean, talking a List interface, and all the operations that can be perfomed on a list, make a List an abstract data type.
You can add things, remove things, count things, iterate, sort, print, ect.

At what point does an abstract data type become concrete? All the data is hidden, and there can be concrete classes without any data held inside them. From a theoretical point of view, is any class that can be instantiated a concrete type, or is there more to it?

Just asking for my own knowledge. I never really thought about defining an abstract class, and I can see from my first post that I don't
really understand.

I am always amazed at how much I still don't know about computer science.

In practical terms, outside of the classroom, people don't use the terms abstract data type and concrete data type very often. We just talk about data types and let how specific we are about implementations provide the context about which kind we're talking about. For example, describing A* there's an open list and a closed list. These are abstract data types, because when describing A* all that matters is what operations can be done on the open list and closed list. However, when implementing A* then you might want to use a priority queue based on an array for your open list so you can easily grab the minimum cost node.

At least part of the reason that we don't use these terms very often is that, outside the classroom, the line between abstract and concrete data type isn't particularly firm. For example, the definition of a std::vector in the C++ standard omits implementation details, but it's so specific that there are really very few ways that you can implement it. In particular there are big O guarantees for standard library types that go a long way in restricting implementation details.

However, if you are in a classroom, then abstract data types just define operations and concrete data types have implementations.

In practical terms, outside of the classroom, people don't use the terms abstract data type and concrete data type very often.

I've seen ADT used a bit by C-educated colleagues. Where a C++-based programmer might say "abstract base class", or a Java programmer might say "interface", these guys would say "abstract data type", but we'd all mean the same thing.
e.g. the abstract part//Java guy says:
public interface Interface
{
int DoStuff();
}
public class InterfaceFactory
{
public static Interface Create();
}
//C++ guy says:
class ABC
{
public:
static ABC* New();
virtual ~ABC() = 0;
virtual int DoStuff() = 0;
};
//C guy says
typedef struct {} ADT;
ADT* ADT_Create();
void ADT_Destroy(ADT*);
int ADT_DoStuff(ADT*);And the (hidden) concrete backing://Java guy says:
public class Concrete implements Interface
{
public int DoStuff() { return 42 };
}
public class InterfaceFactory
{
public static Interface Create() { return new Concrete; }
}
//C++ guy says:
class Concrete : public ABC
{
public:
int DoStuff() { return 42; }
};
static ABC* ABC::New() { return new Concrete; }
//C guy says
typedef struct {} Concrete;
ADT* ADT_Create() { return (ADT*)malloc(sizeof(Concrete)); }
void ADT_Destroy(ADT* o) { free(o); }
int ADT_DoStuff(ADT* o) { return 42; }

I'm a little confused as to what I should have written still.

I'm a little confused as to what I should have written still.

Someone correct me if I'm wrong, but I think this would've been better:

[...] it[s] was a group of similar data types in[/s] is a class (or data type) [s]together[/s] that [s]performed[/s] declares a series of possible operations that my be performed on it, often with declared but undefined member [s]Mutations and accessing[/s] methods. it [s]also[/s] makes the data [s]processes[/s] and representation of the actual object hidden from a programmer and gives a common interface that may be used to abstractly interact with an underlying, possibly unknown concrete type [s]that may just use the accessor and mutator methods to achieve what is needed with the driver[/s]. For example, an abstract List type can declare a common interface for accessing and storing items sequentially. It does not require the underlying storage to use a contiguous array or a linked list; it makes no mention of class member objects (how the data is stored is abstracted away). Instead it provides a common, abstract interface that one may use to implement or interact with a concrete type (like an ArrayList or LinkedList). The concrete data type may then be abstractly treated as a generic List that fulfills the abstract List's contract (that is, you can sequentially store and access items, and you don't care if you have an ArrayList or a LinkedList; all you care about is the fact that you have a List).

Or something like that...

I always define an ADT to other students like this:
An abstract data type specifies a component's interface via signatures (e.g. "new: --> Stack, push: Stack x T --> Stack, size: Stack --> Integer") and it's visible behavior via axioms (e.g. "size(new()) = 0, size(push(A, x)) = size(A) + 1") but makes no statements at all about it's implementation.