Fog Creek Software
Discussion Board




Abstraction Layers

(http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=155213)

In this earlier post,  The Rock asked how Innovation, Abstraction, Productivity, and Functionality were related.  His main point was:

"I think the Win32 API inspires innovation and gives greater
functionality at the cost of abstraction whereas the .NET environment has abstractions that give greater productivity at a cost of functionality-> (Having to declare API calls and not having the exact same functionality as the Win32 API available natively in .NET.) "

So this raised the question -- what makes a good abstraction layer?

To manage the complexity of a solution, you want to arrange it in a hierarchy of modules/objects.  What is a good criteria to use for doing this?  What makes a good hierarchy?  Where the 'abstraction' layer is the bottom layer of your hierarchy, giving you access to machine services.

So can we evaluate the Win32 API versus the .NET API against some criteria?  Can we perhaps develop this criteria based on lessons learned in the "API war"?

(There are other API's that could be added in here as well)

I think he makes a good point -- that the 'level' an API is defined to (the abstractions the API insists you use) can increase your productivity, while at the same time stifle your innovation (that 'insists' word).

So what would make a good criteria?

AllanL5
Wednesday, June 23, 2004

"A function should do one thing, and do it well."

Nearly Nameless
Wednesday, June 23, 2004

>> "I think he makes a good point -- that the 'level' an API is defined to (the abstractions the API insists you use) can increase your productivity, while at the same time stifle your innovation (that 'insists' word)."

Dog gone it AllanL5 you read my mind.  Wish I could express myself as succinctly as you do.

The Rock
Wednesday, June 23, 2004

I think a good abstraction layer is one that does not abstract away functionality because it's the functionality of the underlying API that inspires innovation.  Encapsulation may account for increases in productivity.

So one of my criteria for an abstraction layer for the Win32 API would be 'Do not abstract away functionality.'

I can obtain the bitmap of a particular glyph using the Win32 API function GetGlyphOutline.  I can then render that bitmap anyway and anywhere I choose.  The next higher function 'TextOut' allows me to do the same thing but the functionality of GetGlyphOutline is 'scattered' about in various other API calls and structs and some of the functionality is simply lost.  In the .NET API I would have to use DrawText(? not sure of name) to render a glyph.  DrawText is an even higher abstraction that simply does not expose the functionality of GetGlyphOutline.  DrawText is designed to do the things that most developers would want to do but it is not useful for the creative work that some developers would like.  Sure it supports Unicode and does some other fancy things, but it's just not quite right for what I use it.

Which may bring up another obvious criteria: 'Provide layers of abstraction within the API'.  This will give access to the required functionality.  Layer 1 gives the functionality of the Win32 API.  Layer2 gives the functionality of .NET etc etc.  (This one may be a little awkard)

Not sure if this stuff makes sense but I'll try to explain better if need be.

The Rock
Wednesday, June 23, 2004

A good abstraction layer (incomplete list):

- Is at the same level of abstraction throughout
- Is internally consistent in its logic, structure and form
- Does not block access to lower-level abstractions (functionality)

Should be working
Wednesday, June 23, 2004

A good "Abstraction" does not expose implementation-level details.

I guess that's a slightly long-winded way of saying I don't want it leaky.

Captain McFly
Wednesday, June 23, 2004

GDI calls could be abstracted - hell, should be abstrated - because they were 29 parameter based function calls.  Other wackiness like GetWindowsLong should just never had existed in the first place.

Borland's ObjectWindows was the first to rationalize the Windows GUI API (which is merely a subset of Win32), which made it usable in the first place.

Not knowing anything about .Net, I would guess that it sanely rationalizes all things graphical, and MFC, Message Crackers (aptly named) and even Petzold should probably be given their last rights.

hoser
Wednesday, June 23, 2004

I think it is wrong to say that abstraction limits innovation.  Rather, abstraction move the focus of innovation.

When abstraction is done right, it produces a stable foundation upon which new areas for innovations can be developed.

I think that this is the key to a good abstraction.  Abstractions can be judged by what can be built upon them.

Compilers as a successful abstraction.  When coding in C or VB I never find myself having to think about registers or stacks.  That is all taken care of for me.

File systems are another good abstraction.  I just save and load files, I never worry about how they are stored on disk.  I did have to once, back when it was necessary to Defrag every couple of months and changing my cluster size could have a big impact on peformance or space.

COM, on the other hand, is a poor abstraction.  Just developing and maintaining a fairly simple VB program I find myself having to worry about binary compatability and GUIDs. 

For example, I find myself having to regularly dig in the registry to trouble shoot client problems with COM components.  Memories of looking at the file allocation table using Norton Utilities are a distant memory.

Ged Byrne
Wednesday, June 23, 2004

I think file systems are a lousy abstraction.  Loading and saving files is easy to do, but many other common operations didn't make it into the filesystem -- like "watch this folder, and tell me when its contents change".  ...which is why everybody has his own little add-on to do this (Windows has one way, Irix has FAM, ...), which are all different, and never part of the filesystem.  To me, this is a necessary part of a system of files, yet it's absent from all major filesystems.

I can think of other things I'd do very differently if I was designing an abstraction for a "file system" based on what I actually use as a developer (metadata, searching, ...).  Current filesystems seem to be pretty much "the simplest thing we needed to write, back when VAXes were cool".

h.h.
Tuesday, June 29, 2004

*  Recent Topics

*  Fog Creek Home