Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Does encapsulation mean that variables by default need to be private?  RSS feed

 
Raed Tabani
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just recently started learning about encapsulation, how to set variables private and only accessible to other classes through setters() and getters(). I've seen a couple of programming examples, perhaps not enough but some from here, and I sort of built the assumption that by default all variables need to be private.
to make things more clear, here's a card dealer I made which simply
1- generates a fulll deck of 52 cards
2- lets user decide how many players, with 5 as Max number allowed as each player is dealt 10 cards.
3- deal cards

I approached this by making A deck , card , player and game class









I can understand why for example Deck class's suit and number arrays are set to private , as they only need to be accessed by this class only. however, as you guys noticed both the Deck class's deck arraylist and the Player class arraylist are not private, as I need to transfer these values from one to the other and it felt to me that setting them to private would make it more difficult to deal with them, but what I did instead is to set the
Game class dealCard(), which is the only method that have access to them as private.
does this achieve the same effect or do I need to set both of these arrayList to private?

----
a follow up question, this is more related to the actual card dealer program, in this code

is there an API in ArrayList class that moves(adds to receiver and remove from giver) element across ArrayLists?
 
Dave Tolls
Rancher
Posts: 2914
36
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For your card arrays they should be encapsulated.
That way you can simply do in the Game code:

and leave the implementation of those two methods (addCard and drawCard) to the relevant classes.
At the moment the Game class has to handle the addition of the card as well as its removal from the array in the Deck class.

And a minor point, but that should be Card, not Cards. An instance of that class represents a single card, not several cards.
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A couple of comments:
-- Suit and rank attributes in a deck of cards are better represented by enums rather than a String and an int.
-- Your class that represents a card (singular) is called Cards (plural). That's misleading. Why not name it Card?

All that matters to the user of the Deck class is that it can supply a Card. How it does that and how the remaining cards are stored is an internal matter of the Deck. So yes, its ArrayList should be private, and Deck could have a public or package-private method Card getCard().

Similar logic would apply to the Player class.

is there an API in ArrayList class that moves(adds to receiver and remove from giver) element across ArrayLists?

Hint: what does the remove(int) method return?
 
Raed Tabani
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:For your card arrays they should be encapsulated.
That way you can simply do in the Game code:

and leave the implementation of those two methods (addCard and drawCard) to the relevant classes.
At the moment the Game class has to handle the addition of the card as well as its removal from the array in the Deck class.

And a minor point, but that should be Card, not Cards. An instance of that class represents a single card, not several cards.


hi Dave,
but why they "should" be encapsulated? to me it seems as if to say each class mind your own variables. but I guess on the positive side, it does forces you to implement methods to their relevant classes, as you said.
so right now, I'll be implementing DrawCard() in Deck Class and addCard() in Player class
 
Raed Tabani
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Darryl Burke wrote:A couple of comments:
-- Suit and rank attributes in a deck of cards are better represented by enums rather than a String and an int.
-- Your class that represents a card (singular) is called Cards (plural). That's misleading. Why not name it Card?

All that matters to the user of the Deck class is that it can supply a Card. How it does that and how the remaining cards are stored is an internal matter of the Deck. So yes, its ArrayList should be private, and Deck could have a public or package-private method Card getCard().

Similar logic would apply to the Player class.

is there an API in ArrayList class that moves(adds to receiver and remove from giver) element across ArrayLists?

Hint: what does the remove(int) method return?


it returns, in my case, the card to be removed
so my new code will become


about the enums, being unfamiliar with them, I want to ask why are they better to represent my cards suits and numbers? from my brief and very recent knowledge of the enum Class I sort of built this picture of it as a global Array with constant values, that is accessable across classes. so in a way is it to overcome the restriction imposed by encapsulation and private modifiers since multiple classes need to use them?
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raed Tabani wrote:
Dave Tolls wrote:For your card arrays they should be encapsulated.

but why they "should" be encapsulated?

Darryl Burke wrote:All that matters to the user of the Deck class is that it can supply a Card. How it does that and how the remaining cards are stored is an internal matter of the Deck.


When you expose the ArrayList -- the internal storage of the Deck -- users of the class can invoke any method of the list. You wouldn't want a Player or any other class to add cards to the deck's list or remove all the cards, would you?
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raed Tabani wrote:about the enums, being unfamiliar with them, I want to ask why are they better to represent my cards suits and numbers? from my brief and very recent knowledge of the enum Class I sort of built this picture of it as a global Array with constant values, that is accessable across classes. so in a way is it to overcome the restriction imposed by encapsulation and private modifiers since multiple classes need to use them?


More importantly, an enum represents a finite set of constant values. More here: The Java ™ Tutorials: Enum Types.
 
Dave Tolls
Rancher
Posts: 2914
36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raed Tabani wrote:
hi Dave,
but why they "should" be encapsulated? to me it seems as if to say each class mind your own variables. but I guess on the positive side, it does forces you to implement methods to their relevant classes, as you said.
so right now, I'll be implementing DrawCard() in Deck Class and addCard() in Player class


And that bit (in bold) is exactly it.
If I read the Deck class with the encapsulation in place I can see exactly how that array is modified, and in what circumstances.
As soon as I expose that array to the outside world (ie other classes) then all bets are off.
It could be (and is) changed anywhere...as Darryl says. There's nothing to stop someone doing all sorts of strange things with that data.

That is one of the purposes of encapsulation. It allows you to hide how data is stored, and prevent other code from manipulating that data except in ways that the owning class allows.
In the case of Deck, it allows a caller to request a Card.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!