Using Get and Set Might Be Something You ll Regret

This is too common mistakes. Programmers who are trying to write object-oriented code decided to make all their data private variables when creating public get () and set () function pairs for each of them. See " & quot;? They argue, as they express themselves on their backs. " These data private, but it can be accessed through these functions. I realized my data. That& 39;s what object-oriented design requires ".

I think that this shows the basic (and very common) misunderstanding of what is encapsulation and concealment of information. Ideally, in object-oriented design, software user class should have no idea what types of data contained class. As far as he was concerned, the class must simply provide the required services, and its internal parts should be invisible. However, when we offer to get () and set () function pairs for each member variable, we basically declaring the existence of this data for the world. Hiding information provided by this class is weak, and probably does not exist. You can change the name, type or performance data that member variable, but its existence remains painfully evident to all.

(Note that I say that the user should ideally " & quot; will forget the type of data contained in the class. In practice, this is not always possible. If we were to implement BankAccount class, for example, most programmers will immediately guess that this class will have the accounts as one of its members data. They will also be on the right-guessing so that the owner of the account may be data, while a member. Nevertheless, we must avoid the disclosure of such details, especially when the content of the class are not so easily discerned.)

In Indeed, these get () and set () member functions almost as bad as performing public figures. Of course, they may provide some useful services, for example, set () function can verify the data, ensuring that it is in the proper range. Nevertheless, they tend to violate the spirit information is hidden, at least to some extent.

Using get () and set () functions is not always a bad idea, in fact, sometimes they make perfect sense. Their frequent use, however, is fairly good indication of poor software design abstracted-one that does not adhere to the principle and hiding information. In developing software classes, we have to think primarily in terms of providing services that they (ie their public functions) than they will contain data. Ideally, their implementations should be based on the data required services, rather than vice versa.

To illustrate this concept, let us rededicate BankAccount class mentioned earlier. Obviously, the BankAccount object will need to monitor its balance, so let that data member. It starts with a programmer (or one with the poor to take advantage of object-oriented) could return both GetBalance () and SetBalance () function for this class but it makes sense?

What happens when a user tries to make a deposit? The user will have to call a GetBalance (), add the amount, and then set new value through GetBalance (). That& 39;s not how real users are working, although in the real world, there is no need for investors to know how much money in the account. This class design gives the user too much information and require too many steps.

Similarly, to carry out the withdrawal, the user will need to call GetBalance (), deduct the amount of withdrawal, and then propose SetBalance (), to update your account. It also requires too much work for the user& 39;s part. In the real world, the user should not always be necessary to know exactly how much money in the account. This person might want to know that there are sufficient funds, but it does not necessarily need to know the exact balance, and this information should not be a permanent requirement.

A reasonably written class must provide the following services instead: DepositAmount (), WithdrawAmount () and GetBalance (). In this design, a member of data-account balance-logically implied services, rather than vice versa. (We could identify other services such as AccrueInterest () and TransferFunds (), but let& 39;s keep it simple now. Note that these services could offer additional data members, for example, AccrueInterest () suggests that these members will be filled at the rate of interest.)

In summary, get () and set () function couples do not are bad, but they could assume the preponderance of bad abstracted software design. There is nothing basically wrong with the help get () and set () function when they are part of a set of reasonable services. There is nothing wrong with data members to reflect these functions. When someone runs in the opposite direction, though, when one starts with data-members, it adds a corresponding gain () and set () pairs-This shows the strong poorly conceived software design.



Bookmark it: