I am making a knight's tour implementation in java, and currently I have everything jumbled into one giant mess of code.
I have a class called MainFrame which includes the code to solve the knights tour as well as methods for the menu, etc.
I want to create a new class called KT (for knights tour) which will contain the code for the algorithm, but I'm having lots of issues doing that.
I don't want to post code here because i dont want someone from my class copying or something, so I will just briefly explain.
In class KT, I have declared the variables, arrays, etc. I have methods such as printSolution, move, redo (the backtracking), etc.
However I am unsure how to tie in the code for the buttons (which is declared in MainFrame). For example, I have a loop in the print method that prints the correct solution on the 8x8 board. Right now I'm being asked to create a new method for the button even though I have the button in class MainFrame.
I have a KT k = new KT(); and then I'm launching MainFrame. Is that where I am doing it wrong or is it something really simple that I'm being too dumb to figure out?
tl;dr program works well when i have everything in one class, but i want to make two classes and make everything "look" nice
First of all, give your KnightTour class an actual name. Like, you know, KnightTour. If you were coding this for cash money, the next guy who had to read your code would want to punch the guy who called a class something like KT.
Think about creating this class so that you can use it from a GUI controller like your button and menu laden applet. But so that it can ALSO be used from, say, a character based application where you type commands at a prompt and have your new class evaluate those commands.
The reason I suggest this is because it will force you to create your KnightTour class so that it is PURELY the "business logic" for your app. By that I mean that your KnightTour class should not know anything about buttons, menus, GUIs, text interfaces, or anything like that. You need to think about your KnightTour class in terms of what it must accomplish.
I don't really know what KnightTour does. So I'll just throw out some ideas of what kind of functionality it might need to support. I'm assuming everything takes place on a chess board?
Get the state (occupied, unoccupied) for a given board location (x,y)
Put a chess piece (piece enumerator) on a given location (x,y)
Validate placement of a piece (piece enumerator, location x,y)
Suggest a move, returning a Suggestion object with a piece enumerator and location
Reset the board to start all over.
Now, when you push a button that says "place a piece on 5,5" then you'll handle that event in your GUI controller, and then call the "set piece" method (#2 above) to do that work. If you have a character based application, when you type "put knight at 5,5" then you'll parse that text, and then invoke #2 above. The key point is that both of those user interfaces access the same KnightTour methods to do the same work.
In the actionPerformed method of your MainFrame class just call the appropriate methods to get the solution from KT (which, by the way, I would rename to KnightsTour...readability counts).
Ideally you want all your logic (the model) broken up into sensible methods in KnightsTour, and all your display and button-handling code (the view and controller) in MainFrame. If that's difficult, it's a good sign that you need to rethink how you divided things into methods (and what you're doing with global state...which is frowned upon).
I'm sorry I can't be more specific--I'm kind of hand-tied since you didn't post code.
Related
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
I wrote a simple little maze game for a terminal which repeatedly asks the user to do something (e.g. "In which direction would you like to go? [N/E/S/W]"). I have a navigate() method running in a loop that fires off these questions, stores their answers and does something depending on the answer.
public enum Dir (N, E, S, W);
public void navigate() {
Dir nextDir = utils.askDirection("Which way do you want to go?");
// Do stuff with answer, like changing position of user in maze
}
Now, I've written a simple GUI for my game. I deliberately put all the references to the terminal in a ConsoleUtils class which implements a Utils interface (this has methods like askQuestion()) - the idea being that I could create a GuiUtils class and have my game either as a terminal game or as a GUI game.
The problem is that the navigate method asks the user a question and then "waits" for the response, which the Utils class gives it by using a Scanner to read the newest line of input. However if I use Event Listeners for the new N/E/S/W buttons in my GUI, they fire off events regardless whether the navigate method has asked for one or not.
--> Image of GUI
Is there any way I can combine this or do I need to write a new navigate method for the GUI?
(To be honest, I'm also not entirely sure whether my GUI class should instantiate a game class, in which case the logic for navigate could end up in a GUI method anyway, or whether the game should have a GUI. I haven't written any code for the event listener either yet, since I'm not sure which class should be calling which. This is probably a separate question.)
Your text based game has a loop that repeatedly asks questions to gather user input. Swing provides this loop for you by continually executing Runnable blocks of code that have been posted to the EventQueue. For example, when the user presses a button labeled E, code is posted to the queue that invokes your ActionEvent implementation to handle your game's interpretation of the move east command.
For reference, a complete example of a very simple guessing game is examined here. In pseudocode, the corresponding text based game might look like this:
initialize
loop
prompt "Guess what color!"
get chosenColor
if chosenColor = actualColor
say "You win!"
reset game
else
say "Keep trying."
end loop
A more elaborate game cited there includes the original text-based source.
Hi everyone I am making a simple Libgdx game on Android that involves touching the screen and hitting things. However I have came across a slight problem. I have a small selection of weapons to choose from but I don't know what the best way is to actually draw/access the selected weapons. They are all inherited from a basic weapon class. Right now I have a normal hammer class and a fast hammer class which extends hammer.
The fast hammer has some special methods and swings faster. When I just instantiate the classes I want to test it works fine. However I want to do a check to see which hammer has been selected beforehand and then access it and draw it. I can't think of a very elegant way to do this other than a whole mass of if statements.
I originally tried giving a check variable an int. Then If int 1 then hammer = new normalhammer(); else if int 2 then hammer = new fasthammer(); but this clearly won't work because my hammer variable is assigned to the normalhammer class i.e. Hammer hammer; What is the best way to do this thanks.
Hammer hammer;
FastHammer hammer;//this obviously won't work because duplicate names
if(selected==1){//this was the plan but again won't work because duplication
hammer = new Hammer();
}
else if (selected==2){
hammer = new FastHammer();
}
hammerframe = hammer.HammerAnimation.getKeyFrame(hammer.hammerTime+=delta, false);
//then accessing the class variables won't work because again hammer is a duplicate field. I basically want to check what the check int is and then set hammer to the right class based on that int and the rest of the code will automatically retrieve what I need. Is this possible?
Well, here's how I would do it.
Make all your weapon classes implement some interface/superclass that will help with rendering
Keep an "armory" of weapon objects, one for each weapon type
When the player selects a weapon, set the representative existing object into a "current weapon" variable
For rendering, use the existing "current weapon" variable
Then you don't need to deal with the different types in the renderer - it's abstracted behind the interface!
I'm trying to get a grasp on a couple concepts. Lets imagine you have a JFrame and in that JFrame there are two panels, we'll say left_half and right_half. If I click a button in right_half, I want something to change in left_half. The issue is that the right half doesn't know the left half exists. So, you could tell the Frame, but technically neither panel knows the Frame exists either, right? The Frame can change the panels, but panels can't change the Frame, or so it seems to me.
So, I pass a reference to the Frame into the panels. Now the right_half can call Frame.setVariable(data) and the Frame can, from that same method, say left_half.setStuff(data). That just seems wrong to me and I have been looking for a way to do it without passing references up and down the hierarchy.
Next, someone says "That's why Observable exists!!" Cool, I think to myself. I then found many confusing examples of how to use Observable that didn't help at all. Finally I see this one, which makes sense.
http://www.javaquizplayer.com/blogposts/blogpost7.html
However, it has this: "observable.addObserver(mainWindow);" mainWindow is the equivalent of Frame in my example above, and it had to pass a reference to attach the Obserable to! So even with Observable, I have to pass references down the hierarchy?
It just seems wrong. If it's not wrong, that's fine... I can do it this way. However, my question once all that back-story is finished is simply this: how are you supposed to pass data between two panels? I'm okay with abstract answers if they're in plain language, I'm okay with code samples if they're short and easy to follow. I'm not a pro Java coder, I can't just search through 29 API pages and 1400 lines of code and just suddenly understand how it works... yet. I'll get there.
The observable pattern (in the form of event listeners) is OK and is good practice. You see, even though RightPanel knows someone might be listening to all its events, it does not know who is listening. Well, technically, it could go through all its listeners and use reflection to find out who they are; now, that would be bad practice.
As it is, RightPanel knows someone might be listening to it, and that's all. Components are always aware someone might be listening, since the whole Swing is based on it. What matters is that RightPanel compiles without LeftPanel (or frame), and is completely decoupled from it, except via the listener interface. Not only cool, but standard.
As a side note, your class structure does not have to mirror your nesting panel hierarchy. Depending on what you are doing, it may be entirely fine to control behavior of both left and right panels from inner classes within Frame. (Personally, I'd use a JPanel, not a JFrame, since it allows for more flexibility, but this can be easily refactored). Otherwise, you risk splitting your View/Controller into too many closely coupled classes, and that would violate encapsulation and cause a lot of boilerplate code. Normally, I don't code big fat classes and try to refactor them into smaller ones; Swing is usually an exception. Better one big fat class than a maze of densely coupled classes. Unless of course you have a reusable component or some piece of functionality that can be clearly and intuitively decoupled; not just a couple of buttons or checkboxes that have no meaning in and of themselves. The simple fact that some subcomponents are situated within a certain panel in a component tree should not be a major factor IMHO.
For that matter, I usually don't nest JPanels; I use MigLayout and make all components into siblings. Matter of taste! I'd just encourage you to check out MiGLayout first and see whether you like it.
I have finished writing a Hangman game, but I want to move the hangman out of the canvas when the game is over. I create that hangman with any partition of his body. When I move the object it can move only one object at a time. How can I bunch them together?
You have to create an object of the class GCompound. This class of object allows you to create new object that can be manipulated like GOval and so. In the Stanford course, there is an example called GFace.
Probably you can refactor your code to make the whole hangman one object through the whole implementation and whenever needed make different parts visible. When the time comes to remove him, just dispose of the whole thing either by resetting them to non-visible or try making a new object I guess... If you cna post the code of your implementation I may be able to give you some more help...