3

As part of my learning i think the best answer(with meaning) for definition of abstraction that i found is from stackoverflow:

What is abstraction?

Besides that,

As part of current online course cs61B Fall 2006, Berkeley, i learnt the similar below definition of ADT close to above definition but added an extra word 'invariant'. Shall i consider this word as corollary to the above definition? or Is this word part of the definition?

An _Abstract_Data_Type_ (ADT) is a class that has a well-defined interface, but its implementation details are firmly hidden from other classes. That way, you can change the implementation of a class without jeopardizing the programs that depend on it. The Date class is an ADT.

ADT allows you to enforce invariants.

An invariant is a fact about a data structure that is always true (assuming the code is bug-free), no matter what methods are called by external classes. For example, the Date ADT enforces the invariant that a Date object always represents a valid date. An invariant is enforced by allowing access to certain fields only through method calls.

Community
  • 1
  • 1
overexchange
  • 15,768
  • 30
  • 152
  • 347
  • The meaning of "abstraction" is, er, abstract. Generally, in computing, it means a model or description of some system or component which "hides" irrelevant details. An "invariant" is a tool for documenting (and possibly testing/verifying) a system. It is basically a statement of some condition that is always true. I suppose it sorta assumes there is some abstraction to describe, but the two concepts are not tightly linked. – Hot Licks Mar 05 '14 at 01:21
  • FWIW: To my knowledge the concept of "invariant" goes back to the late 60s or perhaps early 70s and was championed (I'm pretty sure) by E. W. Dijkstra. The concept of "abstraction" also dates from that era, but they were independent concepts at first. Dijkstra was deep into "formal verification" and "proof of correctness", where equations ("invariants") stating what the program did would be written out and somehow processed to "prove" a program correct. He never really perfected the concept, but many of his ideas were incorporated into "structured programming". – Hot Licks Mar 05 '14 at 17:06

1 Answers1

4

One of my favourite definitions of abstraction is Robert C. Martin's, from the book Agile Principles, Patterns, and Practices:

Abstraction is the elimination of the irrelevant and the amplification of the essential.

Based on that definition, an abstraction can take many forms, on many different levels:

  • It can be an entire system
  • It can be a subsystem
  • It can be a definition of a message format (akin to a protocol)
  • It can be a function (as in Functional Programming)
  • It can be an abstract base class
  • It can be an interface
  • It can be a concrete class
  • etc.

In Object-Oriented Software Construction, Bertrand Meyer describes classes as Abstract Data Types. The idea in this book is that the description of an Abstract Data Type includes pre- and post-conditions. In Eiffel (the language used in the book), these are called assertions, but we also know them as invariants.

Meyer's view on Object-Oriented Design includes invariants. On a detailed (class/object/function) level, I agree that it makes sense to view invariants as a way to describe an abstraction.

On the other hand, if your abstraction is a description of a high-level architecture, those kind of invariants doesn't make sense. Still, even at a high level, it would often be valuable to define pre- and post-condition (e.g. "System A must be responding in order for System B to work correctly"), so it does makes sense to think about invariants in relation to abstractions.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • so mark, How would you consolidate the definition? so that i cannot turn back and think of the definition again. – overexchange Mar 05 '14 at 08:48
  • From your point: "makes sense to view invariants as a way to describe an abstraction" Would you like to say that Abstraction is nothing but enforcing invariants? – overexchange Mar 05 '14 at 11:54
  • 1
    It's more than invariants; a good abstraction is often also a metaphor. – Mark Seemann Mar 05 '14 at 12:05
  • @RubenBartelink - But if it's *like* ordering coffee it's a simile. – Hot Licks Mar 06 '14 at 12:35
  • 1
    @HotLicks Yes, pendantically you might ordinarily be correct and I'd leave your comment unaddressed. But you don't have a smiley... We're not on http://english.stackexchange.com - we're on SO. While Mark's first language was not English, it generally appears his second one was Software Architecture; hence he doesn't apply a term like **metaphor** loosely. http://en.wikipedia.org/wiki/Simile says *Generally, metaphor is the stronger and more encompassing of the two forms of rhetorical analogies.* So, back to Mark's point - A good abstraction *is* a **metaphor**. – Ruben Bartelink Mar 06 '14 at 16:25
  • Like, man, don't have a calf! (Is that a metaphor or a simile?) – Hot Licks Mar 06 '14 at 16:41
  • 1
    Actually, the main thing about an abstraction is that it hides "irrelevant" details, producing a simpler conceptual model to deal with. In this sense considering it a metaphor can be distracting and counter-productive, if the metaphorical model has details that do not map to the original interface. Pretty much everything you deal with in computing is an abstraction, but only rarely does one map to a metaphor to any significant degree. Mainly metaphors (and similes) are useful as pedagogic tools or discussion points, not as rigorous models/descriptions for a (er) "concrete" abstraction. – Hot Licks Mar 06 '14 at 17:03
  • @HotLicks Yes, a simile is like a metaphor. But Mark is talking about a metaphor. And a System Metaphor is a thing. And he was alluding to it. And you're not wrong about all the things you're saying about similes. But it's a side point at best. But you're not going to give up. But I am! – Ruben Bartelink Mar 07 '14 at 09:52
  • @RubenBartelink - Close as I can tell from the link, a "System Metaphor" is like a box of chocolates -- you never know what you're going to get (and they're likely to melt all over your hands and make a mess). (The link does not at all define the term.) (And I've just realized that the project I'm on now suffers from metaphoria -- much of it is described using metaphor-based terminology, and there's not a common understanding of those terms. Hence "communication is did", but understanding suffers.) – Hot Licks Mar 07 '14 at 12:41
  • @HotLicks I selected the one I linked to based on that wiki generally being authoritative but it may not be the best source. Here's [a more readable looking article](http://xp123.com/articles/the-system-metaphor/) and a [presentation](http://www.slideshare.net/wwake/the-system-metaphor-explored). As covered in [this SO Q](http://stackoverflow.com/questions/211557/what-is-a-metaphor-in-the-context-of-xp) a System Metaphor, while potentially powerful if there is a good one, definitely has cons - up to and including being corny :) – Ruben Bartelink Mar 07 '14 at 14:14
  • @HotLicks As with much of Xp, there's lots of extremely well thought out ideas but also, as with anything, there's always plenty room for misinterpretation and misunderstanding too. For me Mark's central point - **a good abstraction is often also a metaphor** stands and is a __lot__ less waffly than either of our ramblings :P – Ruben Bartelink Mar 07 '14 at 14:16
  • I wonder if it isn't better to use the term "analogy", since that's more up-front with the nature of the beast. – Hot Licks Mar 07 '14 at 16:39