• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Multi-layer encapsulation?

 
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I put this together from one of the questions used in 1z0-808 exam. What I wanted to checkout is, if method setBill had a private access, would using addKwh1 method present a more robust encapsulation design than using addKwh method?

Thanks
 
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think about this: if someone just calls setBill() without calling the addKwh() or addKwh1() method, will the object still be consistent?

Also, what do you mean by "multi-layer" encapsulation? Do you even have encapsulation with this design?
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Junilu Lacar
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?


I'm not exactly sure I understand what you mean by that but I'm sure that's not what I'm saying.

How do you see this code as being encapsulated? Also, you still haven't explained what you mean by "double multi-layer encapsulation".
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me get away from the way the question was posed on the 1z0-808 and change it to the way I think it makes sense to achieve encapsulation - lets see if it is correct.

If would move ,
 


to the class ElectricAccount and change access modifiers for addKwh, addKwh1, and setBill methods to private.

As for what the topic means, what I am really asking in general, if there is such a thing as creating multi-layer encapsulation by having private access methods call on other private access methods in the same class, deepening the level of encapsulation.
 
Junilu Lacar
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You keep saying "multi-layer encapsulation" as if anybody else knows what you mean by that. Again, what does that even mean? What do you consider as a "layer of encapsulation"?
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Since you did not reject my solution, does that mean the way I changed the code around, achieved encapsulation?

2. Well I couldn't find any explanation or wording in Oracle docs for what I was looking for, so I called it multi-layer encapsulation as a concept to find out if an encapsulated method needs to call another method within the same class, does it make sense (or a need) to encapsulate the method being called as well?
 
Marshal
Posts: 65467
249
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How do you know nobody ejected your solution? They spent all their time trying to work out what the question is about. It doesn't do any good to create new term,s o to use established terrms to men something different.
I would like to see the whole of the new version of your code before saying it is or isn't encapsulated. Actually it isn't because the acct field in line 3 isn't private. What is the point of securing the front door if you leave the back door open?
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, I want to apologize for wasting everyone's time by choosing a badly worded topic. I worded so it represented the concept that I was asking about; I never thought that it would be taken literally. I'll be very careful as for the topic next time.

Second, as for my little encapsulation testing code, I've modified it so the access modifiers are set to bare minimum that is needed for the methods and variables to be accessed. If this does not accomplish encapsulation, I appreciate any hints.

Thanks

 
Junilu Lacar
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Let's go by the definition of "encapsulation" as given here: https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

2. Let's ignore the fact that the code in ElectricAccount is somewhat nonsensical.

Based on the cited definition and the fact that all data fields are declared private and all the work done to manage their values is done within the same class, you could say that makes this class more or less encapsulated.

As far as the correctness and usefulness of the code itself is concerned, however, that's an entirely different story.

 
Campbell Ritchie
Marshal
Posts: 65467
249
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jake Monhan wrote:. . . a badly worded topic . . . I never thought that it would be taken literally. . . .

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 wor‍d 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.
 
Marshal
Posts: 7084
491
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the difference between the methods:
addKwh
addKwh1

?
 
Junilu Lacar
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I'm beginning to understand what Jake is referring to as "multi-layer encapsulation" ... I believe the idea is around the Customer having a private ElectricAccount object which it calls in a non-public method.

No, this is not an additional "layer" of encapsulation. There's no such thing. Customer is merely another client of ElectricAccount. The fact that ElectricAccount is private in Customer does not make ElectricAccount "more encapsulated."

Let me draw an analogy for you. You, as a person, are "self-contained" or encapsulated. You have a heart, lungs, and everything else that keeps you alive. Nobody else can manage your organs and bodily functions. If I put you inside a high-security prison, does that make you any more self-contained/encapsulated? It doesn't right? You are still as self-contained/encapsulated as you would be outside in a crowd of people. The only difference really is that inside a high-security prison, not that many people will be able to interact with you as there are if you are out in the world, roaming freely.

Same thing with your ElectricAccount. 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."
 
Junilu Lacar
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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."


Let me clarify this a bit since abstraction and encapsulation are somewhat related to each other.

There is some encapsulation involved here when you have a private ElectricAccount in a Customer object. But the encapsulation is not about ElectricAccount, it's about Customer. Customer provides a useElectricity() method. To the outside observer, this is the only thing they can access in the Customer. They don't know about the private ElectricAccount nor can they manipulate it directly. To affect the ElectricAccount object, you have to go through the useElectricity() method. Again, this has nothing to do with ElectricAccount being encapsulate but rather with Customer being encapsulated.

It's valid to say "Customer encapsulates an ElectricAccount" here but it's nonsensical to say "ElectricAccount has more layers of encapsulation" because it doesn't--there's no such thing as multiple layers of encapsulation. Something is either fully encapsulated or it's not.

Speaking of jargon, "layer" is probably not the best term to use here. Certainly, you can have a design that is more encapsulated around one attribute that it is around another. For example, let's say you have an object with a field that only the object itself can manipulate directly and another field that can be manipulated directly from outside the object. We could say then that the degree or extent of encapsulation of that object is  less than if you designed it so that both fields can be manipulated only by that object.

In this case, we'd say the first design (one field encapsulated, the other field isn't) is less encapsulated than the second design (both fields encapsulated). But it's not right to say that the second design has an "additional layer" of encapsulation because it doesn't.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone for driving the message home.

Junilu Lacar wrote:As far as the correctness and usefulness of the code itself is concerned, however, that's an entirely different story.

Yes this was a pure exercise as to how much a class and its variables and methods can be encapsulated.


Liutauras Vilda wrote:What is the difference between the methods:
addKwh
addKwh1

?



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
Sheriff
Posts: 13730
228
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?!


No, I don't think it does. Remember, encapsulation is about an object's internal data and operations and their relationship to outside influences. Calling setBill() from one of the addKwh() methods is an internal matter and has nothing to do with encapsulation per se, in my opinion.

Now, changing accessibility of setBill() from public to private does affect the degree of encapsulation you have in an ElectricAccount object. If you make the method private, then you have more encapsulation. If you make it more accessible, then you'll have less encapsulation. This is particularly true for a setter method.

But again, "less or more" encapsulated is different from "another layer" of encapsulation. You talk about encapsulation in terms of less/more, not layers, of which there are none.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 wor‍d incorrectly.



Less or more. I'll be sure to use these terminology in the future to avoid creating unnecessary confusion. Not to mention to keep the sergeants happy.
 
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!