This post is part of a series aimed at bringing people up to speed in what’s going on today in application development.

Finally, the fourth pillar, Abstraction.  Abstraction is the principle of reducing complexity by hiding the details when possible.  Abstraction takes many forms in practice (hey, it’s polymorphic!).  In one sense, Abstraction is very much a part of Encapsulation, in that you are hiding the dirty details of the implementation and encapsulating it in a pretty API.  In another sense, Abstraction is closely related to Polymorphism, in that if you have a SportsCar, you could treat it abstractly as a Car in some cases, and concretely as a SportsCar in others.  Abstraction can also be seen when you “wrap” functionality further down the complexity chain.

Think back to our overloading example:

public DataSet QueryTable(string tableName)
{
     //query tablename with Select * from tableName
}

In this example, we are seeing Abstraction at work.  To the caller of the QueryTable function, the way you get data from a database is to make a call to QueryTable and provide a table name.  If only it were really that simple!  The reality is you have to connect to the database, put together a SQL query, execute the query, receive and parse the results, and so on.  By Abstracting those details into a simple function call, you make it so that you don’t have to include the code for querying a SQL database everywhere in your code that you query a SQL database.  This makes the code many times more maintainable.  If the method for querying the database changes in ADO.Net 2.1 then you only have to change the single implemented method, and because of encapsulation, any calling code would still work.  Consider the alternative, which would be searching the entire codebase and making the change everywhere a database query happened.

If you think back to the example in encapsulation, the ASP mail sending.  That’s abstraction at work.  Starting with Server.CreateObject(“CDONTS.NewMail”).  Server is the object, CreateObject is the method, and you have no idea what goes on inside of CreateObject but you know it gives you a usable “mail” object.  Abstraction..  You don’t have to worry about the inner workings of creating a COM object instance to use, because it does it for you.  And if the method for creating that object ever changes, you don’t need to worry about that either (theoretically speaking…bear with me) because as long as “CreateObject” still exists in the API, and it still returns your “mail” object, you’re good to go.  Finally, mail.send is a method call that sends the email to your recipient.  You don’t have to know RFC 822, you don’t have to know how to interact with an SMTP server (hell, you don’t even have to know that SMTP exists when you do the ASP version!), you just say “mail.send” and off it goes.  Abstraction.

Object oriented programming is itself an abstraction.  You can do all the same stuff in a non-object oriented way, but the OO gives you a way to think about and organize the code in a logical way.  Any high level computer language you use is an abstraction.  Your computer doesn’t know public void SomeFunction(){…} from public sub SomeFunction…End or anything in between.  It knows 100101010010101001010101011010101101010101.  Gratz to you if you can program in binary.  I need the abstractions to be productive thank you very much.

Joel Spolsky has what he calls the Law of Leaky Abstractions.  It’s a good read and very true.  But leaky or not, the abstractions, even on the trivial level of providing a wrapper method for querying a database, are better than the alternatives