This question was answered in "Understanding Abstract Data Types (ADTs)", and the top voted answerer (by Frank Shearar) is currently as follows:

Objects are not ADTs (*) [editor's note: Links to "On Understanding Data Abstraction, Revisited" - Cook]. (So in C# String and Int32 are not ADTs.)

With that out of the way, an abstract data type "has a public name, a hidden representation, and operations to create, combine and observe values of the abstraction". (Quoting from the linked paper.)

(*) Briefly, Cook explains that:

  • Objects cannot inspect the hidden representation of other objects, unlike members of an ADT. That implies that values of an ADT may be
    implemented efficiently, even for operations that require inspection
    of multiple abstract values.

  • Objects behave like a characteristic function over the values of a type, rather than as an algebra. Objects use procedural abstraction rather than type abstraction

  • ADTs usually have a unique implementation in a program. When one's language has modules, it's possible to have multiple implementations of an ADT, but they can't usually interoperate.

My problem is with the second bullet point.I think that in the paper linked, it just happens to be the case that for the specific example of a set used in Cook's paper, an object can be viewed as a characteristic function. I don't think that objects, in general can be viewed as characteristic functions.

Also, in the paper Aldritch (The power of interoperability: Why objects are inevitable) suggests

Cook’s definition essentially identifies dynamic dispatch as the most important characteristic of object

agreeing with this and with Alan Kay when he said

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

However, in these set of lecture slides it suggests that Java classes are ADTs while Java interfaces are objects - and indeed using interfaces "objects" can inter-operate (one of the key features of OOP as given in one of the bullet points above).

My questions are

  1. Am I correct to say that characteristic functions are not a key feature of objects and that Frank Shearar is mistaken

  2. Are data that talk to each other through Java interfaces examples of objects even though they don't use dynamic dispatch? Why? (my understanding is that dynamic dispatch is more flexible, and that interfaces are a step towards objective-C/smalltalk/erlang style messaging)

  3. Is the idea of dependency inversion principle related to the distinction between ADTs and objects? (see the wikipedia page or google "The Talking Objects: A Tale About Message-Oriented Programming". Although I'm new to the concept, I understand that it involves adding interfaces between "layers" of a program (see wikipedia page diagram)

  4. Please provide any other examples/clarifications of the distinction between objects and ADTs, if you want.

closed as off-topic by ChrisF Jan 14 '16 at 12:17

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  1. No. Objects are well known today to involve a mix of data and functions. Removing the functions means you don't have an object any more.

  2. Yes. Interfaces still use dynamic dispatch to call the right function depending on the runtime type of the object that satisfies the interface. You are right that dynamic dispatch is often used to mean multiple dispatch, where more than just the this parameter can cause dispatch, but the limited dispatch is still enough for objects.

  3. Not particularly. I mean, since ADTs are just data, there's no dependencies to invert. You could look at function objects over ADTs as a sort of dependency inversion, but the ADT doesn't own them.

  4. Write more code. ADTs have a number of traits that most objects do not. Hell, even most objects do not have the traits of objects. The difference is often in the capabilities of the things. And a lot of those traits become clear once you start using each and understanding how their different capabilities limit your program design and implementation.

  • Thanks for the reply :) By characteristic function I mean the term as it's used in math (this isn't clear in my post, you would have to read Cook's paper). (Also, to anyone reading, I'd recommend reading a paper I referenced - it's a more modern and accessible version of Cook's paper) – LMZ Jan 14 '16 at 2:47
  • @lmz - sorry, it's been a long day and such math is beyond me right now. CS.stackexchange is better for that sort of thing. – Telastyn Jan 14 '16 at 3:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.