Why Abstract Data Types are useful
I recently blogged about using Interfaces to encapsulate code changes in this blog entry. I seem to write about interfaces and Abstract class
Interfaces and Abstract classes - don't design without them
Why Interfaces are better than Abstract classes
Why I found recently is that the idea I was writing about in using Interfaces to encapsulate code change is really talking about Abstract Data Types. The idea being you have an abstract data type (ADT) which then means you don't need to know what the actual data type is, so you code is not linked to any one data type. One of the main benefits of using ADT's is you can then swap the actual data type being used and the rest of your code won't know or care about it because it will only be using the Abstract Data Type.
Interfaces and Abstract classes - don't design without them
Why Interfaces are better than Abstract classes
Why I found recently is that the idea I was writing about in using Interfaces to encapsulate code change is really talking about Abstract Data Types. The idea being you have an abstract data type (ADT) which then means you don't need to know what the actual data type is, so you code is not linked to any one data type. One of the main benefits of using ADT's is you can then swap the actual data type being used and the rest of your code won't know or care about it because it will only be using the Abstract Data Type.
I have recently come across a good example of this whilst working. We have a piece of software which draws images of maps, recently we created some interfaces so that we could use an interface lets say called mapEngine. By using the mapEngine interface we now have the possibility to use different map drawing engines without any of the code knowing or worrying about it.
The important point was that code had to only use the mapEngine and not access the different drawing engines directly otherwise we would be coupling that code with a specific map drawing engine. The important point being made here is that any new code would need to change the mapEngine interface (which is an ADT) so to avoid coupling to a specific data type.
Other popular ADT's are things like List and Java Collections are a good example, you have the ADT of List but really this list could be a LinkedList, ArrayList etc.
here is a link to wikipedia if you are hungry for more information and another quick link I found
I'm sure there are many other better resources and just typing in Abstract Data Types should get you on your way to finding more information.
posted by The Hosk at
3:03 pm
3 Comments:
Terminology, again. The term abstract data type has generally meant a theoretical interface for data storage with a fully defined specification, suitable for logical reasoning. An ADT doesn't exist in code, it exists as a set of logic equations. That's what the word "abstract" means in this context.
The value of an ADT isn't substitutability, because there is rarely a need to replace one correct implementation with another correct implementation. The value of an ADT is the ability to use the specification for reasoning about program correctness.
See, for instance, NIST's definition of the term.
Substitutable code implementations (of any interface, not just data storage) generally fall under the Strategy pattern.
By
Doug, at Tue Oct 03, 05:38:00 pm 2006
I think you are correct and maybe I have misunderstood or should I say misused the ADT a little bit. It just struck me that the description and useage I read about ADT seemed similar to what I was talking about when using interfaces. Although it is in a similar ball park I definitly think I am talking more about a strategy pattern usage.
thanks for explaining the concept in more detail, I am as always a keen student and I often learn as much through people's comments than when I am reading about the topic to begin with.
By
The Hosk, at Wed Oct 04, 09:28:00 am 2006
Unfortunately, much OO terminology is becoming almost meaningless because influential people like Robert C. Martin grab an existing term and then use it to mean something else entirely. I already commented earlier on Martin's total reversal of the meaning of the Open-Closed Principle.
The poster child of this is, perhaps surprisingly or perhaps not surprisingly, the term Object Orientation itself. Alan Kay is generally recognized as having coined the term, and he regularly complains that what people are doing in the name of "Object Orientation" is not at all what he means by the term.
Whereas Robert C. Martin likes to take existing terms and use them to mean something else, Martin Fowler likes to coin new terms and use them for existing ideas that already have established nomenclature. Between the two of them they have made it almost impossible to discuss OO in a rigorous manner because we don't have an established and recognized vocabulary. Somebody says (or writes) one thing, and somebody else hears (or reads) something different.
I'm sure that it's a lost cause, and there's no way that we'll ever have a coherent OO lexicon. But that doesn't stop me from objecting when I see a term being misused.
By
Doug, at Wed Oct 04, 04:48:00 pm 2006
Post a Comment
<< Home