|
| This Article | ||
| ||
| Share | ||
| Bibliographic References | ||
| Add to: | ||
 Digg  Furl  Spurl  Blink  Simpy  Google  Del.icio.us  Y!MyWeb | ||
| Search | ||
| ||
Data Access Routines
November/December 2003 (vol. 20 no. 6)
pp. 96-98
| ASCII Text | x | ||
| Martin Fowler, "Data Access Routines," IEEE Software, vol. 20, no. 6, pp. 96-98, November/December, 2003. | |||
| BibTex | x | ||
| @article{ 10.1109/MS.2003.1241375, author = {Martin Fowler}, title = {Data Access Routines}, journal ={IEEE Software}, volume = {20}, number = {6}, issn = {0740-7459}, year = {2003}, pages = {96-98}, doi = {http://doi.ieeecomputersociety.org/10.1109/MS.2003.1241375}, publisher = {IEEE Computer Society}, address = {Los Alamitos, CA, USA}, } | |||
| RefWorks Procite/RefMan/Endnote | x | ||
| TY - MGZN JO - IEEE Software TI - Data Access Routines IS - 6 SN - 0740-7459 SP96 EP98 EPD - 96-98 A1 - Martin Fowler, PY - 2003 VL - 20 JA - IEEE Software ER - | |||
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. As David Parnas observed, modules should be arranged around system secrets, each module hiding its secret from the others. Then if the secret thing changes, you avoid a ripple effect.One of the most common secrets to hide these days is data structures. This column discusses guidelines for basic data hiding. The examples all use objects, but the arguments apply just as well to non-OO modules.
Citation:
Martin Fowler, "Data Access Routines," IEEE Software, vol. 20, no. 6, pp. 96-98, Nov.-Dec. 2003, doi:10.1109/MS.2003.1241375
Usage of this product signifies your acceptance of the Terms of Use.