Object-Oriented encapsulation is the packaging of operations and attributes representing state into an object type so that the state is accessible or modifiable only via the interface provided by the encapsulation
In other words, it's the encapsulation of the state within the procedural mechanisms for accessing and modifying the state
The payoff of good encapsulation is supression in the public view of the myraid details to be seen in the private view.The supression takes two forms : information hiding and implementation hiding.
Information/implementation hiding is the use of encapsulation to restrict from external visibility certain information or implementation decisions that are internal to the encapsulation structure.
However, the term "information hiding" addresses only part of what a good encapsulation may hide.Encapsulation often reveals information but hides implementation.This aspect is vital to object orientation: The variable inside an object that remembers the information provided by the attribute doesnot need to be implemented the same way as the attribute itself, which is available to other objects.
In future redesign, we might decide to reveal the direction information and to provide an operation to export the direction attribute to other objects.But even then, we'd retain implementation hiding because we still wouldn't need to know whether the implementation within the object was the same as that of the public information.
For example, we may decide that the object should hold direction internally in the character form and - after converting it - export it publicly in angle form.In other words,the operation that provides the value of this attribute could convert it from an idiosyncratic internal representation to a numeric angle that most people would want to see as the attribute direction.
Information/implementation hiding is a powerful technique for taming software complexity.It means that the object appears as a black box to an external observer.In other words, the external observer has full knowledge of what the object can do, but has no knowledge of how the object may do it or how the object is constructed internally.
Originally posted by Desai Sandeep:
The variable inside an object that remembers the information rovided by the attribute doesnot need to be implemented the same way as the attribute itself, which is available to other objects.
A better design would have Person asking Account to give him back an Amount that indicated his totalAssets. This is like going to the bank and asking the bank officer "What are my total assets?" The bank officer goes into a secure (encapsulated) room and goes through your account records, comes back out and gives you an envelope marked "CONFIDENTIAL", saying "Your answer is in this envelope." That is the kind of professional service I would expect from a bank.
Originally posted by Junilu Lacar: Try this: when you write a getter method, try to think about why you need that information. Then ask yourself why can't you just ask the object that has the information to do something for you?
Originally posted by Caroline Iux:
I think if you look at the figure from another perspective. Look at the "end use" as a customer of a bank, the "person" in the figure as a bank officer. Then it is doing what you expect it to do. The "Person" doesn't just give the "end user" all the accounts back, and say "Here, you go figure out your balance yourself." Instead, the "Person" calculates the balance( sealed in an envelope if you like ), then give it back to the end user.
A classic smell is a method that seems more interested in a class other than the one it actually is in. The most common focus of the envy is data. We've lost count of the times we've seen a method that invokes a half-dozen getting methods on another class to calculate some value.
Originally posted by Junilu Lacar:
If you were to implement totalAssets() in Person, you would have code like this:
Amount totalAssets() {
Account aAccount;
Amount amount = new Amount(0);
Iterator iterator = new AccountList(this);
while (iterator.hasNext()) {
aAccount = (Account)iterator.next();
if (aAccount.isAssetAccount())
amount.add(aAccount.getBalance());
}
return amount;
}
Notice that the method isn't even interested in any features of Person. It's only interested in the features of Account as exposed by the getters isAssetAccount() and getBalance(). So what would such a method be doing in Person?
Originally posted by Junilu Lacar:
Going by my principle of role-reversal: ask yourself why a user (another class or actor) would ask Catalog for a list of Products or a Product. What would a user of Catalog need the list or product for? Will this lead to another case of feature envy or some other bad code smell? (see my previous post) Could the code smell be avoided by asking the Catalog to something with the Product/ProductList instead?
David Roberts - SCJP2,MCP
David Roberts - SCJP2,MCP
Originally posted by JUNILU LACAR:
The point I am trying to make is that the responsibility of going through Accounts, checking if they are assets or not, and summing up the balances, is more appropriately assigned to the Account class, not the Person class.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted By David Roberts:
You don't really know everything you need to know to decide whether you're increasing coupling or not.
My cellmate was this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|