| Home | Free Articles for Your Site | Submit an Article | Advertise | Link to Us | Search | Contact Us |
This site is an archive of old articles

    SEARCH ARTICLES
    Custom Search


vertical line

Article Surfing Archive



Using *Get* and *Set* Might Be Something You'll Regret - Articles Surfing


It's an all-too-common pitfall. Programmers who attempt to write object-oriented code decide to make all of their data variables private, while creating public get() and set() function pairs for each one. *See?* they declare, as they pat themselves on their backs. *The data is private, but it can be accessed through these functions. I*ve encapsulated my data. That's what object-oriented design requires.*

I think this betrays a fundamental (and exceedingly common) misunderstanding of what constitutes encapsulation and information hiding. Ideally, in an object-oriented design, the user of a software class should have no idea what type of data the class contains. As far as he's concerned, the class should simply provide the required services, and its internal details should be invisible. However, when we provide get() and set() function pairs for each member variable, we are basically announcing the existence of this data to the world. The information hiding provided by this class is weak*and arguably non-existent. One might change the name, data type or implementation of this member variable, but its existence remains painfully obvious to everyone.

(Note that I say that the user should *ideally* be oblivious to the type of data contained within the class. In practice, this is not always feasible. If we were to implement a BankAccount class, for example, most programmers would immediately guess that this class would have the account balance as one of its data members. They would also guess*rightfully so*that the owner of this account is likely to be data member as well. Nevertheless, we should avoid needlessly divulging such details, especially when the contents of a class are not so easily discerned.)

In effect, these get() and set() member functions are almost as bad as having public data. Sure, they may provide some useful services; for example, the set() function could validate the data, ensuring that it is within the proper range of values. Nevertheless, they tend to violate the spirit of information hiding, at least to some degree.

Using get() and set() functions is not always a bad idea; in fact, sometimes they make perfect sense. Their frequent use, however, is a pretty good indication of a poorly abstracted software design*one that does not adhere well to the principle of information hiding. When designing software classes, we need to think primarily in terms of the services they provide (i.e. their public functions), rather than the data they contain. Ideally, their data implementations should proceed from the required services, rather than other way around.

To illustrate this concept, let us revisit the BankAccount class mentioned earlier. It is clear that the BankAccount object will need to keep track of its balance, so let's make that a data member. A novice programmer (or one with a poor grasp of object orientation) may choose to provide both GetBalance() and SetBalance() functions for this class* but does this make sense?

What happens when a user attempts to make a deposit? The user would have to call GetBalance(), add the deposit amount, and then set the new value using GetBalance(). That's not how real users operate, though; in the real world, there is no need for the depositor to know how much money is in the account. This class design gives the user too much information and requires too many steps.

Similarly, to perform a withdrawal, the user would need to call GetBalance(), subtract the withdrawal amount, and then call SetBalance() to update the account. This also requires too much work on the user's part. In the real world, the user should not always be required to know exactly how much money is in the account. This person might want to know that there are sufficient funds, but he wouldn*t necessarily need to know the precise balance, and this information should not be a constant requirement.

A sensibly written class should provide the following services instead: DepositAmount(), WithdrawAmount() and GetBalance(). With this design, the data member*the account balance*is logically implied by the services provided, rather than the other way around. (We could define other services, such as AccrueInterest() and TransferFunds(), but let's keep it simple for now. Note that these services might suggest additional data members; for example, AccrueInterest() would suggest that a data member would be needed for the interest rate.)

In summary, get() and set() function pairs are not inherently bad, but their preponderance could suggest a poorly abstracted software design. There's nothing inherently wrong with using get() and set() functions when they form part of a sensibly designed set of services. Nor is there anything wrong with using a data member to reflect these functions. When one proceeds in the opposite direction, though*when one starts with the data members, then adds corresponding get() and set() pairs*that's a strong indication of a poorly conceived software design.

Submitted by:

V. Berba Velasco Jr., Ph.D.

V. Berba Velasco Jr., Ph.D. is a senior electrical and software engineer at CTL (http://www.elispot-analyzers.de, http://www.immunospot.com, http://www.elispot.cn, http://www.elispot.co.jp), a biotech firm that provides ELISPOT technology, cryopreserved PBMCs and serum-free media.



        RELATED SITES






https://articlesurfing.org/computers_and_internet/using_get_and_set_might_be_something_youll_regret.html

Copyright © 1995 - Photius Coutsoukis (All Rights Reserved).










ARTICLE CATEGORIES

Aging
Arts and Crafts
Auto and Trucks
Automotive
Business
Business and Finance
Cancer Survival
Career
Classifieds
Computers and Internet
Computers and Technology
Cooking
Culture
Education
Education #2
Entertainment
Etiquette
Family
Finances
Food and Drink
Food and Drink B
Gadgets and Gizmos
Gardening
Health
Hobbies
Home Improvement
Home Management
Humor
Internet
Jobs
Kids and Teens
Learning Languages
Leadership
Legal
Legal B
Marketing
Marketing B
Medical Business
Medicines and Remedies
Music and Movies
Online Business
Opinions
Parenting
Parenting B
Pets
Pets and Animals
Poetry
Politics
Politics and Government
Real Estate
Recreation
Recreation and Sports
Science
Self Help
Self Improvement
Short Stories
Site Promotion
Society
Sports
Travel and Leisure
Travel Part B
Web Development
Wellness, Fitness and Diet
World Affairs
Writing
Writing B