I have been learning java and data structures in java lately. I am dealing with this problem , this would be the first sort of real program i will be coding up . Up to this point i have only wrote code for short algorithms and data structures. So i was kind of looking for guidance on how i can approach this step by step. I am not looking for any code as i don't learn by looking at other peoples codes rather i needed guidance in how i should approach such a problem ..ex. do i first determine which classes i need etc? So after surveying the problem i realize this problem can be made as detailed or complicated as we like but i am trying to keep it simple do the basic that is required. So the following is what i have gathered so far.
I need a Customer class that will include name, age, number of grocery items bought, and method for determining which queue to join(join the shortest queue).
I need a several Customer queues that are associated with "checkers" who take random time to process each customer.
I would need a supermarket class where all the interaction between the customer, the queue and the checker would take place.
I am confused as i don't know where to start at the moment and also right now i don't have a clear idea on how everything will come together. I would really appreciate if someone can provide me step by step guidance as to what i should do in which order. By doing so it will help me in the future when i write more code for other object oriented languages.
I highly appreciate all inputs and apologize if have asked anything inappropriate.
In general, you need a main loop that repeats over and over and handles input and all entities you have (customers, groceries, etc.)
Since you want the supermarket class to manage your program, I would start with that.
You will then realize that you need a customer in your supermarket.
So create that class when you need it.
Then you will realize you need groceries.
So create that class when you need it.
Then you will realize you need to create the instances for these classes.
That would happen inside the supermarket in your case.
So far, nothing has been made 'viewable' and no interaction with the program is possible.
It creates customers themselves. Adds groceries to them (e.g. in an ArrayList property of the customer).
Then you will realize you need Ques.
So create them.
Time for each customer could depend on the number of items times a random factor.
Now you have your supermarket running. You should add debug logging that you can maybe turn off so you see what's happening.
Now, if you want, you can create something where you can view the supermarket's statistics or however you want to visualize.
Then, create the input for the user. Remember that you are running an infinite loop. You can ask for user input on each iteration. When input is present, react accordingly.
Now: fix bugs, add features, test, fix bugs, add features, test, ...
I hope this is a high-level overview that will help you get started.
Don't be afraid that your classes are to simple at the start. You can always add functionality to them at a later stage when the rough program is running.
Related
I have been coding in java for about a year and a half, and have made some small games and programs that I think turned out very well. The problem is that I am mostly self taught and I most of my code and class structure is not organized or "correctly structured". This didn't matter to me for the smaller things I made, but if I were to take on a larger project I would want to structure it correctly and make it organized.
In a previous mini-RPG game I had
Main Class (Main loop + Main method)
Player Class (containing player position and player stats)
Engine Class (containing map and collision detection between player and map
Map Class (containing map data)
My Main class contained an instance of Player and of Engine, and Engine had an instance of Map. The problem is that Player then could't tell the Engine where it was, and the Engine couldn't adjust Player's position and stats when something happened on the Map. So I ended up having some static variables and methods in both Player and Engine to get them to communicate.
I guess my overall question is is this the correct structure of classes, and is it correct to use static methods and variables here? If not, how would you structure these classes, or would there need to be more or less classes?
My overall objective is to understand how to structure classes in this previous game so I can better structure classes in a bigger project I want to take on.
It is a rather broad question, but the general answer is no.
As a rule you shouldn't use static fields to connect instances. (There are a couple of possible exceptions, but as a rule of thumb it's a useful one.) The basic idea of OOP is that everybody has a reference to whoever they want to send messages to. So if a Player needs to tell the Engine something, it should have a reference to whichever Engine instance it belongs to. Or you can redesign your architecture so only Engine sends messages to Map and Player, it's difficult to tell without more detail about your setup whether that would be appropriate in this case.
Another piece of general advice is to try to sit down with a piece of paper, write down the name of all three of your classes and in a separate column write down all the things the system has to do. And then you should try to figure out who's responsible for what. In a good design this decision is simple, if you find yourself shoehorning different things into one class, that's a sign that you should maybe need a more detailed model with more classes.
I would also suggest you take a look at the observer pattern and the publish-subscribe pattern, as it might be what you need.
Try take take a look at some design-patterns.
Which design pattern you want to use depends on what you prefer. Some can be found here on Wikipedia.
I also take it that you are familiar with OOP? Some more general info can be found here on Wikipedia.
Looking at your specific story, I think a MVC-design would be a nice solution.
MVC meaning Model View Controller.
Here you have your Model, classes holding different forms of data.
Your Controller, controls your Model, contains all the real logic.
And your View, this is the graphic end of your application.
You'd probably want to put and instance of your player in your engine as well. That way your engine will control everything (the player and the map). Hope that helps!
From what you described there a few possible ways to handle this. One would be to use a messaging system. I would look into Java Messaging Service (JMS). Another would be to make your app event drive. Here is a neat little tutorial on how to do this using spring : https://spring.io/guides/gs/messaging-reactor/. Having said that, if your intent is get a better understanding of problem solving using Java, I would first try and mimic these two approaches on your own, without any bulky frameworks.
I am trying to write code for my latest class assignment where we create a Harness Record System, the code needs to keep track of Harness's in a system, be able to create new Harnesses and edit/loan/check old ones. I have gone down the route of using a GUI rather than the console as it is easier for the user to use. Although, I'm having trouble coming up with ideas on how to write code that differentiates old Harnesses written into the code, with new Harnesses that overwrite the previous input of the user.
So my question is, is there any way to write a code that can create objects once the user clicks a certain button, so that when that button is clicked the information inputted by the user into that object comes up, rather than just the most recent input of the user.
I know this is a silly and badly worded question, but my brain is just fried at the moment, I'm in need of help.
My code is below, I'm using two different classes and the SWT kit, if anyone could have a look at my code and help me out I would be so grateful, really struggling to find a way to overcome this:
Harness Class: http://pastebin.com/HqJqGfTN
HarnessSelection Class: http://pastebin.com/EE4C2WCs
The 'new' keyword is how you create new object instances. I haven't read all of your code but make sure you understand what the 'static' keyword does - it makes all instances of that class share the same value for that field. Perhaps all of your harness instances are sharing the same static variables.
I'm working on a moderate-sized Java project and trying to stick to the best possible practices, so I thought I'd run a few questions by you guys. Since I currently have time, I want to do it right. My apologies in advance if this sort of question isn't appropriate for StackOverflow. Perhaps others can refer to it for stylistic advice.
I'm writing a class called LinkOpener which has one public, static method: openAgencyWindows. You feed it an (oil) well serial number and, based on the serial number, a opens regulatory website for any one of the 50 US states. I'd be doing quite a bit of scraping, and due to the labyrinthine nature of these websites the code can get pretty extensive. Should I:
Include all of my scraping code in a LinkOpener class, including methods to handle serial numbers that correspond to each state in the US (sorted alphabetically).
Give each state its own class, which would extend a Scraper class that contains a few common website scraping/regex methods. Each state class would have one to three methods to assist with scraping.
Do something else?
Any assistance would be much appreciated.
Your second alternative will be more readable and a more object-oriented approach, which is good. It is also possible to call methods in the specific classes without knowing what state it is through abstract methods in the implemented class.
I am about to start my newest project, it is basicly an application that gets some data from a database and then display that data a graph!
now even though that this may seem simple it is important to me that this is done in a very correct way when it comes to object orientated programming.
Now my idea was the following:
I wanted to create the following four classes:
Adapter:
The class that connects the application to the database and recives the data
CallQueue:
This is an object that differences depending on what type of data is recived from the database and what type of data you wish to show on your graph. An example of this would be Cheese and fruits. both of them are food but they are very different types of food.
Statistics
This would be a tool class used to calculate the information recived from the database (for example changeing it to percentage instead of raw data)
Graph
This would be the class that gets the information from the statistic class and turns the numbers into a graph
GUI
This is ofcourse the GUI class where i will post the graph on!
Now i want to make the project as object orientated as possible. But my problem is that the information from the database is not always the same. For example if get the data from a day to day basis it will be different than from month to month. This means that the information is always going to change depending on what the user need.
How would i make this program object orientated ? and what type of connections should my classes have to eachother to make it most accessible. Do i have to create subclasses in order to simplify it?
should i add all information from the datbase directly into the CallQueue Class or should that object be created later on?
Update - Elaboration
The name callQueue is not a streaming implementation it is marely an object that should contain values of the data recived from the database (note that this is still in the idea phase and nothing is implemented). The idea is that a user opens the program and then chooses a day from and then a day to for instance: 04/11/2012 to 10/11/2012. The reason the objects value changes is when the day changes for instance to the following: 04/11/2012 - 04/12/2012 then a new graph will be created new information from the database will be calculated ect ect.
One thing that i am confused about aswell is the following:
When you have an object that is created from the database (adapater Note this could be optimized if you guys have a better idea) then how would you calculate statistics from that? would it be better that the statistic class called the adapter for data then worked with the data and then created the objects contain the calculated data?
Then the Graph class would need to get the objects data and insert into the graph.
From experience designing large systems and even smaller, the best approach is to think in terms of components rather than classes. This will allow you to break down your problems into smaller (and mostly independent) pieces.
So for example, you will have a component which sole responsibility will be to bring the data to your application for processing. That component will need to be able to deal with the multiple data sources, etc... That then becomes a sub-system that you can design independently from the rest of the application and deals with a specific problem, smaller than the whole.
If the sub-problems are still larger than they should, keep breaking them down into sub-compoennts, until the implementation of the components becomes almost trivial. At that point, you can start bringing in the notion of classes because you have enough visibility on the protagonists in your system.
In short, I put a lot of emphasis on separation of concerns. By isolating sub-problems into sub-components, you also isolate the solutions which makes it easier to correct your design mistakes or replace implementations without impacting the entire system.
Just my two cents...
Whenever I try to write graphical programs (whether a game or really any GUI app) I always wind up with one or two god classes with way too many methods (and long methods, too), and each class having far too many responsibilities. I have graphics being done at the same time as calculations and logic, and I feel like this is a really bad way to go about organizing my code. I want to get better at organizing my code and abstracting out responsibilities to different classes. Here's an example of where I'd like to start - I want to write a Minesweeper clone, just sort of as practice and to try to improve my software engineering skills. How would I go about making this nice and object-oriented? For the sake of discussion, let's just say I'm using Java (because I probably will, either that or C#). Here's some things I would think about:
should each tile inherit from JButton or JComponent and handle drawing itself?
or should the tiles just be stored as some non-graphical MinesweeperTile object and some other class handles drawing them?
is the 8-segment display countdown timer (pre-Vista, at least) a separate class that handles drawing itself?
when the user clicks, do the tiles have mouse event listeners or does some other collision detection method loop through the tiles and check each one to see if it's been hit?
I realize that there's not just one way to write a GUI application, but what are some pretty basic things I can start doing to make my code more organized, manageable, object-oriented, and just over all write better programs?
edit: I guess I should add that I'm familiar with MVC, and I was originally going to incorporate that into my question, but I guess I didn't want to shoehorn myself into MVC if that's not necessarily what I need. I did searched for topics on MVC with GUI apps but didn't really find anything that answers my specific question.
edit2: Thanks to everyone who answered. I wish I could accept more than one answer..
Here is a simple (but effective) OO design to get you started:
First create a Game object that is pure Java/C# code. With no UI or anything else platform specific. The Game object handles a Board object and a Player object. The Board object manages a number of Tile objects (where the mines are). The Player object keeps track of "Number of turns", "Score" etc. You will also need a Timer object to keep track of the game time.
Then create a separate UI object that doesn't know anything about the Game object. It is completely stand alone and completely platform dependent. It has its own UIBoard, UITile, UITimer etc. and can be told how to change its states. The UI object is responsible for the User Interface (output to the screen/sound and input from the user).
And finally, add the top level Application object that reads input from the UI object, tells the Game what to do based on the input, is notified by the Game about state changes and then turns around and tells the UI how to update itself.
This is (by the way) an adaption of the MVP (Model, View, Presenter) pattern. And (oh by the way) the MVP pattern is really just a specialization of the Mediator pattern. And (another oh by the way) the MVP pattern is basically the MVC (Model, View, Control) pattern where the View does NOT have access to the model. Which is a big improvement IMHO.
Have fun!
use a MVC framework that handles all the hard organization work for you. there's a ton of MVC framework topics on SO.
using high quality stuff written by others will probably teach you faster - you will get further and see more patterns with less headache.
I'm not suggesting this is the only way to do it, but what I would suggest is something like the following. Other people, please feel free to comment on this and make corrections.
Each tile should inherit from something and handle drawing itself. A button seems like the best solution because it already has the button drawing functionality (pressed, unpressed, etc) built in.
Each tile should also be aware of its neighbors. You would have eight pointers to each of its eight neighbors, setting them to null of course if there is no neighbor. When it goes to draw, it would query each neighbor's IsMine() function and display the count.
If none of its neighbors are a mine, it would then recurse into each neighbor's Reveal() method.
For the 7-segment display, each digit is its own class that handles drawing. Then I would make a CountdownSegmentDigit class that inherits from this class, but has additional functionality, namely CountDown(), Set(), and Reset() methods, as well as a HitZero event. Then the display timer itself is a collection of these digits, wired up to propagate zeroes left. Then have a Timer within the timer class which ticks every second and counts down the rightmost digit.
When the user clicks, see above. The tile itself will handle the mouse click (it is a button after all) and call its Reveal() method. If it is a mine, it will fire the MineExploded event, which your main form will be listening to.
For me, when I think of how to encapsulate objects, it helps to imagine it as a manufacturing process for physical parts. Ask yourself, "How can I design this system so it can be most efficiently built and reused?" Think about future reuse possibilities too. Remember the assembly process takes small pieces and builds them up into larger and larger pieces until the entire object is built. Each bit should be as independent as possible and handle its own logic, but be able to talk to the outside world when necessary.
Take the 7-segment display bit, you could have another use for it later that does not count down. Say you want a speedometer in a car or something. You will already have the digits that you can wire up together. (Think hardware: stock 7-segment displays that do nothing but light up. Then you attach a controller to them and they get functionality.)
In fact if you think hard enough, you might find you want CountUp() functionality too. And an event argument in HitZero to tell whether it was by counting up or down. But you can wait until later to add this functionality when you need it. This is where inheritance shines: inherit for your CountDownDigit and make a CountUpOrDownDigit.
Thinking about how I might design it in hardware, you might want to design each digit so it knows about its neighbors and count them up or down when appropriate. Have them remember a max value (remember, 60 seconds to a minute, not 100) so when they roll over 0, they reset appropriately. There's a world of possibilites.
The central concern of a Graphic User Interface is handling events. The user does X and you need to response or not respond to it. The games have the added complexity in that it needs to change state in real time. In a lot of cases it does this by transforming the current state into a new state and telling the UI to display the results. It does this in a very short amount of time.
You start off with a model. A collection of classes that represents the data the user wants to manipulate. This could represent the accounts of a business or vast frontiers of an unknown world.
The UI starts with defining a series of forms or screens. The idea is that is for each form or screen you create a interface that defines how the UI Controller will interact with it. In general there is one UI Controller classes for each form or screen.
The form passes the event to the UI Controller. The UI Controller then decides which command to execute. This is best done through the Command design pattern where each command is it own class.
The Command then is executed and manipulate the model. The Command then tells the UI Controller that a screen or a portion of a screen needs to be redraw. The UI Control then looks at the data in the model and uses the Screen Interface to redraw the screen.
By putting all the forms and screen behind a interface you can rip out what you have and put something different in. This includes even not having any forms at all but rather mock objects. This is good for automated testing. As long as something implements the Screen Interface properly the rest of the software will be happy.
Finally a game that has to operate in real time will have a loop (or loops) running that will be continually transforming the state of the game. It will use the UI Controller to redraw what it updated. Commands will insert or change information in the model. The next time the loop comes around the new information will be used. For example altering a vector of a object traveling through the air.
I don't like the MVC architecture as I feel it doesn't handle the issues of GUIs well. I prefer the use of a Supervising Controller which you can read about here. The reason for this is that I believe automated tests are one of the most important tools you have. The more you can automate the better off you are. The supervising presenter pattern makes the forms a thin shell so there is very little that can't be tested automatically.
Sorry to say it, but it seems you have mess in your head trying to improve your coding too much in one step.
There is no way to answer your question as such, but here we go.
First start with OOP, think about what objects are required for your game/GUI and start implementing them a little at a time, see if there are chances to break up these objects further, or perhaps reunite some objects that make no sense on their own, then try to figure out if you have repeated functionality among your objects, if you do, figure out if this repeated functionality is a (or many) base class or not.
Now this will take you a few days, or weeks to really grok it well, then worry about dividing your logic and rendering.
I have some tutorials that are written in C#. It discusses this very same topic. It is a starting point for a RogueLike game.
Object Oriented Design in C# Converting Legacy Game
Object Oriented Design: Domain Type Objects
Object Oriented Design: Rethinking Design Issues
BROKEN LINK - Object Oriented Design: Baby Steps in Acceptance Testing