Jake Monhan wrote:So are you saying that addKwh method and in turn if setBill method's access were to change to private, addkwh1 method do achieve encapsulation independently?
We talk jargon.and lots of people think that is confusing. No, jargon is a special vocabulary used in a particular field. The Military are particularly strong on jargon, but they have sergeants who will tell the privates off if they use a word incorrectly. Every jargon word has a precise meaning to those who speak it, so “overriding” and “overloading” might sound similar, but they mean something completely different.
Jake Monhan wrote:. . . a badly worded topic . . . I never thought that it would be taken literally. . . .
Junilu Lacar wrote:Being referenced as a private field inside a Customer object has no bearing on whether or not ElectricAccount is encapsulated. It just means that Customer object has a very limited way of interacting with an ElectricAccount. That's not encapsulation. That's more along the lines of the idea of "abstraction". If there's any "additional layer" here, it's one of "abstraction."
Yes this was a pure exercise as to how much a class and its variables and methods can be encapsulated.
Junilu Lacar wrote:As far as the correctness and usefulness of the code itself is concerned, however, that's an entirely different story.
Liutauras Vilda wrote:What is the difference between the methods:
Jake Monhan wrote:This is what started the whole thing. I wanted to find out if having addkwh1 call setBill, will create some sort of additional encapsulation?!
Junilu Lacar wrote:You talk about encapsulation in terms of less/more, not layers, of which there are none.
Campbell Ritchie wrote:The Military are particularly strong on jargon, but they have sergeants who will tell the privates off if they use a word incorrectly.