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.
About the Author:
Article Source:
thePhantomWriters Article Submission Service