Abstraction is one of the four pillars of object oriented programming, but what is it and why is it important?
My take on abstraction is born of experience. Abstraction for me is about hiding detail, removing a need to know about implementation details. This is typically the kind of base explanation I give of abstraction, but the value of it comes in fact from its decoupling. We can provide a layer of abstraction between an object/class and its dependencies, vital if we want to run unit tests and not touch real resources, real filesystems, real databases etc. To benefit from this layer of abstraction we need the ability for the code to handle different types commonly, based on a common base class or interface, i.e. subtype polymorphism.
For what it’s worth, abstraction and polymorphism are pretty tough subjects when you dig deeper but for my purposes as a J2EE developer, abstraction is mainly about allowing tests to run without the need for a real database, real EJB or maybe just without creating a very complex data type which is unrelated to the test at hand.
Here’s a Java tip though, static methods will hinder any attempts at abstraction. Learn where you really need abstraction, typically where you need to avoid touching a resource or certain class in a test, then avoid static methods like the plague. Static methods cannot be overridden, therefore cannot be ‘abstracted out’. I will address this subject in another post…
Any comments/questions welcome.