Object Oriented Programming/Abstraction Barrier

Abstraction Barrier

Data Abstraction

The idea behind data abstraction is to identity certain ways or operations data is expressed and manipulated. Once this is done, the goal is then to use only those operations when it comes to manipulating data. Restricting the use of operations, makes it much easier to change the representation of abstract data without changing a program's behavior.

Examples

A few examples of abstraction barriers can be found in this table from composing programs.com, which demonstrates how different types of abstraction barriers can handle rational numbers.

Parts of the program that...	Treat rationals as...	using only
Use rational numbers to perform computation	whole data values	add_rational, mul_rational, rationals_are_equal, print_rational
Create rationals or implement rational operations	numerators and denominators	rational, numer, denom
Implement selectors and constructor for rationals	two-element lists	list literals and element selection

The last column 'using only' demonstrates an extraction barrier being enforced. The functions are called from higher levels then, implented through a lower level of abstraction.

Abstraction Barrier Violations

Violations occur when a program that has the ability to use a higher level function, instead uses one in a lower level. An example would be referring directly to numerators and denominators in your code rather then just using mul_rational, a function that does not assume anything about how a rational number is implemented.

Composingprograms.com examples -

>>> def square_rational(x):
       return mul_rational(x, x)

Correct: code is simple and makes no assumptions on rational number implementation.

>>> def square_rational_violating_once(x):
       return rational(numer(x) * numer(x), denom(x) * denom(x))

Incorrect: violates one abstraction barrier, by directly referring to numerators and denominaters making code more complex then needed.

>>> def square_rational_violating_twice(x):
       return [x[0] * x[0], x[1] * x[1]]

Also incorrect due too making extra assumption rationals are represented as two element list. This would be considered two abstraction barrier violations.

In short, abstraction barriers make programs easier to maintain and modify, by using as few functions as possible to represent operations so fewer changes will be needed to be made to the code in order to change it's representation. Remember simplicity is better then complexity, especially when it comes to abstraction barriers.