What is the Correct Amount of Abstraction?
The purpose of abstraction in software is to make it easier to modify in the future adding un-anticipated requirements. Rather than trying to think of every possible contingency, build your software so that it can more easily be extended with the least amount of effort. Software having very rigid contracts between components is more difficult to alter without having to modify both the code you want to change, and all consumers of the code.
I think of printer drivers as being a great example of software extraction. An operating system defines an interface for printing that is standardized for all printing from that operating system. Any printer manufacturer can create their own printer driver for their printer, basing it on the interface for any operating system they wish to support. In this scenario the tight cohesion is the interface; both the operating system and the printer driver must support the specification.
In this case the interface would be considered the abstraction. The operating system knows how to instantiate the printer driver (because it is part of the interface) and the printer driver knows how to handle printing commands coming from the operating system. This is the abstraction. There is no code on either side behind the interface.
Should all of your software rely on the same amount of abstraction as that of a printer driver? How much abstraction is enough? Are there any common principles guiding the developer in determining the amount of abstraction to include? Drop a note to btaylor@sswug.org, or leave a comment below. We’ll drill into this a little more tomorrow.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2012 User-Defined Functions
In this article, you can find some tips to use SQL Server 2012 User-Defined Functions.
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)