Any sufficiently refined abstraction is indistinguishable from magic. [source lost]

We abstract by suppressing detail and emphasizing what is common. [James Coplien, "A professional dilemma", C++ Report, Oct 94, p82]

There is no such thing as "absolute truth" when it comes to developing abstractions. The "correct" abstraction is always a function of the "where" and "why" of the desired system. Take the context of a trout, a cow, and a lungfish, and the assignment to identify the creature that is "most different" from the other two. If the request is coming from a restauranteur, the answer is probably the lungfish. If the customer is an aquarium manager, the answer is probably the cow. And, if the interested party is studying the origins of species, the answer is probably the trout. [Grady Booch, "Growing mature abstractionists", Object Magazine, Feb 94, p80]

Meaningful abstractions can never be crafted in the absence of a well-defined [well-understood ??] context. Any abstraction that we try to build without knowing why we are making this classification is usually vacuous, over-engineered, or both. [Grady Booch, Object Magazine, Feb 94, p80]

Abstraction relates more or less to the application domain, and encapsulation more or less to the solution domain. [Coplien, p241]

No one ever wanted a 3/8" drill bit. They wanted a 3/8" hole. [friend of Jesse Liberty, C++ Report, Nov 99, p24]

Abstraction is often the enemy of performance. [James Coplien, "After all, we can't ignore efficiency", C++ Report, May 96, p66]

Although hierarchies are a powerful abstraction construct, the world is not fundamentally hierarchical. At best, a good world model comprises multiple interwoven hierarchies, tangled with flat clusters of related abstractions. [James Coplien, "Setting the Stage", C++ Report, Oct 94, p8]

The principal difficulty of building class structures is not inheritance per se; it is the search for abstractions. If you have identified valid abstractions, their inheritance structure will follow. To find the abstractions, use the theory of abstract data types. [Bertrand Meyer, p862, OO Sw Construction]

Programmers routinely fail to create new abstractions. They write "flat" code, in which all the functionality is at the same logical level. They use subroutines as a glorified macro facility, not as a way to create abstractions. [Lou Grinzo]

The more general problem is often easier to solve, and in programming, the more general design may be easier to implement, may operate faster on the machine, and can actually be better understood by the user. In addition, it will almost certainly be easier to maintain, for often we won't have to change anything at all to meet changing circumstances that fall within its range of generality. [Gerald Weinberg, "Rethinking Systems Analysis and Design", Dorset House, 1988, (from Object Magazine, Apr 96, p20)]

Identifying design secrets that a program's classes, modules, functions, and even variables and named constants should hide from other parts of the application. [Steve McConnell, IEEE Software, Jan 00, p11]

Teaching object technology is not the hard part. It's teaching object mentality that is the real challenge. [David Morley]

"If you have a hard time figuring out the right way to design a class, that is a good sign; it means that you are thinking about it instead of doing the obvious thing." [Ken Arnold, "Class Design for Inheritance", Unix Review, July 94, p72]