• Post Reply Bookmark Topic Watch Topic
  • New Topic

Accessing objects from other packages  RSS feed

 
Larissa Perkins
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have GameConsole class with gamePlay(). There are two objects in this class that I want to access from a class in another package.



Then I have an actionListener that I am trying to write that was originally in the gamePlay() class. It was working perfectly then, but I now want it in the blackjackGUI package, ButtonListener class.



The dealer and playingDeck objects are giving me an error of unresolved. the way it is written I also get a static error on line 37. I know that I have not yet written in the actionEvent statement in the button constructor.

I am new to java and this is a final project that I have pretty much been for that last 2 weeks. I have never done anything with packages before and also nothing with GUI.

ANY help is greatly appreciated but please please please remember that I am new to this.
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This ButtonListener class should not try to manipulate too much of the game, at least not at this level of detail. All it should do is activate behavior in the control classes. A lot of the code that you are trying to put in the ButtonListener should stay in the control classes.

This logic:

should not be in the GUI listener class. That logic makes the GUI class too "nosy"; it's sticking its nose in something that's really none of its business. It should just do something like this:

The GUI listener is the "bridge" between the person using the program and the code that manages the game state, which is actually called the "model", not the "control". The logic that you have in the ButtonListener that I quoted above would go back in the main classes, specifically, the stay() method in a Game class. The Game class would be in the same package as the Dealer and Player class and it would have references to those objects so you can make the appropriate calls.

In other words the design should be:

main: creates a Game

Game: instantiates a Dealer and Player and keeps references to them; initializes the state of the game.

main: initializes GUI objects by calling setGame and passing in the current Game, effectively telling them which game object to invoke behaviors on when user activity is detected.
("Hey, GUI object, this is the game that's being played right now. When the user does something, let this guy know what it needs to do next.")

GUI: (detects that user hit the "Stay" button) -- Hey, game, the user just hit the stay button so do your "stay" thing (call to game.stay())

Game: Ok, ... (executes its stay() method)

Notice that the GUI component that deals with the buttons knows only about Game, not about Dealer and Player, and that it only is aware of general behavior; it knows that a game can have "stay" and "hit" behaviors but it knows nothing about the details of those behaviors, nor does it need to care what those details are.
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does that make sense? I don't know if this is getting a bit too advanced for you but the concepts involved are Separation of Concerns which leads to application layering. It's kind of a chicken-and-egg thing if you think it's too advanced because these are core concepts that you need to understand if you are going to write programs that have this level of complexity, as simple as they may seem. If you don't follow these principles, then you'll run into the exact problems that you're seeing with your current code and design.
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your GameConsole class kind of fits the bill for the Game class that I described although the word "console" in the name implies a GUI aspect, which you should keep out of the "model" Game class. Notice how your GameConsole class has references to the Dealer and Player so you're already half way to the design I described.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Larissa Perkins wrote:ANY help is greatly appreciated but please please please remember that I am new to this.

OK, well my main concern is that you're writing a GUI to play Blackjack; so you're getting tied up in knots with what the GUI does, and not what the game of Blackjack is about.

Junilu touched on it in his previous post, but let me (hopefully) try explain it in basic terms:

1. There is THE GAME of Blackjack, which was around long before GUIs were a twinkle in Turing's (or even Steve Jobs') eye.
2. There is Java Swing, which allows you to represent the game of Blackjack to a user on a screen.

Which of those do you think is more important? The game or the GUI? - Would you even be thinking about writing this GUI if the game didn't exist?

So - assuming you agree with me, and you think the game is more important - Why not start with that?

As long as you're dealing with the game, your life is going to consist of thinking about Cards and Decks and Hands (possibly even Aces). It'll contain verbs like hit and stand and split (even doubleDown if you want to get fancy), and maybe even have a Dealer and Players. ie: You'll be talking the language of Blackjack, not some computerized simulation of it.

But as soon as your world becomes centred on your GUI, you'll be dealing with Icons and Frames and Buttons, and the Events that tie them together.

Do you see how this might not be the best way to go?

Design you GUI around the Game; not your game around the GUI.

HIH

Winston
 
Junilu Lacar
Sheriff
Posts: 11485
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Larissa Perkins wrote:ANY help is greatly appreciated but please please please remember that I am new to this.

There are a few ways we can take your plea to remember that you're new to this. One way is to take it to mean that you are apprehensive that we'll be mean to you in some way and ridicule or make fun of your inexperience. That will never happen in these forums. That's not how we are here.

Another way to see your plea is to take it to mean that you don't know much and you'd like pointers to help you understand more. That's absolutely what we're about around here.

Yet another way is to take it that you are saying that you're not capable enough to understand concepts which you might find too advanced for your current level of experience. To that, I would say that you're going to have a rough time if you're not willing to get out of your comfort zone and tackle these concepts that you find difficult right now. Like I said, some of these things are basic principles of programming and if you don't learn them, then you won't be able to progress much further than knowing basic syntax. Programming is not about syntax; it's about thinking and organizing your thoughts and that's what these basic principles help you do.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!