By Topic

Data access routines

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$33 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)

One of the most important things about good design is modularity: dividing a system into separate pieces so that you can modify one module without the changes rippling all over the system. Early on, it was observed that modules should be arranged around system secrets, each module hiding its secret from the other modules. Then if the secret thing changes, you avoid a ripple effect. One of the most common secrets to hide these days is data structures. An axiom of object-oriented design is that data should always be private, but the idea of hiding data goes far beyond objects. The author discusses guidelines for basic data hiding. His examples all use objects but the arguments apply just as well to non-OO modules. When thinking about data access routines, the author uses two major cases: encapsulating either a single value (such as a person's name) or a collection (such as the line items on an order).

Published in:

IEEE Software  (Volume:20 ,  Issue: 6 )