Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have some trouble finding appropriate patterns for what I want to do.
I have a block game with two game modes. In one mode, any removed blocks are replaced by new blocks dropped from the top of the screen. In the other mode, removed blocks are replaced by a complete new row of blocks rising from the bottom and pushing the whole field up. So I thought it would be best to use the Strategy pattern to implement this.
Now the problem is, that this Strategy would need modifying access to all the positions of existing blocks in the playing field, but obviously that information lies within the Strategy's user class (the Game class) and I can't have circular dependencies.
I could pass the whole field as a reference, but I have the additional problem that all the Block generation code lies within the Game class (as it should in my opinion). So the only thing that comes to mind is pass all these methods as function references, but to me that seems like overkill.
So any way to resolve this? Maybe I'm on the wrong track by wanting to use the Strategy Pattern. Help is greatly appreciated.
Bonus points for any hints regarding the use of two Strategy Pattern objects in a class that need access to the same methods which depend on members in the user class.
I'm coding in Java if that is of help
I guess in the end it was kind of too complex to assume an out-of-the-box answer.
I kind of followed Traxdata's hint of decoupling more together with Mister Smith's suggestion to actually pass references to other objects.
My final solution consists of having a FieldManager, a Field and a Strategy class. The FieldManager contains a Field and Strategy instance. The Field class contains the block creation code.
So whenever blocks need to be created or removed, the appropriate function calls the corresponding Strategy's function and passes a reference to the field. So whenever a Strategy needs to create or remove something in the field it can do so via the field object.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am making a semester project for my University OOP course. I am making a Restaurant Management System as my project.
I have an Order class, Main class, and my constants stored in a class called GlobalConstants.
I read in a post on this site that said constants should be in related classes. In GlobalConstants I have a method running in a static block that reads order data (order no., time, items etc.) from a file and stores it in an ArrayList (static and final) which is accessed by multiple methods in the Main class.
So, can anyone suggest a better way to do this that follows OOP practices?
First, don't create any logic in a class, called GlobalConstants. This is the Separation of Concerns principle.
This made clear, you could:
First: create a util class e.g. FileUtil where you will move your static method. It wont store the result in a field, but will return the result instead (or alternatively take the list as an argument and populate it). Storing (if needed) or whatever other work with the result is needed is the job of the class that is calling the method, not of the util.
Second: I suppose that you have to store the content of your file in memory in order to do something with it for your order. You must decide what is the scope of this data.
If these are some global settings to your applicaton comming from this file - you could easily create a Settings class that will be Singleton (find info and read about Singleton - this will be a good start to get known with Design Patterns).
If it is some session data - maybe the order itself is coming from a file - then store this data in your Order class - this is its purpose after all.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live system
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Suppose I am writing an application for simulating vehicles of all types. Should I now organize packages based on the different type of vehicles e.g.,
com.example.vehiclesimulation.car
com.example.vehiclesimulation.truck
com.example.vehiclesimulation.bus
com.example.vehiclesimulation.motorcycle
or should they be organized in a structure based on the functionality e.g.,
com.example.vehiclesimulation.transmission
com.example.vehiclesimulation.interior
com.example.vehiclesimulation.steering
com.example.vehiclesimulation.electronics
Often package structures get complex as we move deeper into the structure one is clueless whether to form a subpackage or a sibling. In the above case, we could have the ontological packages as parents and then have all the functional ones as their children, and vice versa. So which one is more appropriate and why?
EDIT: It may be noted that this distinction becomes more complicated when there are deeper levels and at each level one has to choose betwen the two axes. Fo instance, should the class XYZHeadlight go under c.e.vehiclesimulation.car.XYZ.electronics or c.e.vehiclesimulation.electronics.car.XYZ or c.e.vehiclesimulation.car.electronics.XYZ?
I think it really depends on the type of package. Your example in not really a good one. I would advice structuring based on functionality, but rewrite the example as follows:
com.example.vehicles.car
com.example.vehicles.truck
com.example.vehicles.bus
com.example.vehicles.motorcycle
but the following "things" are not vehicles - they are parts that can be used in vehicles:
com.example.vehicleparts.transmission
com.example.vehicleparts.interior
com.example.vehicleparts.steering
com.example.vehicleparts.electronics
and now in your car you can use com.example.vehicleparts.transmission.
However sometimes you might want to use package private fields and method, in that case you could put them all in one package to deal with it.
I would structure them based on their functionality. The only reason I got for this is to be able to "share" components between different vehicle types, e.g. a transmission of a truck that is also used on a bus could be better placed in the second (functionality-ontological) structure, I guess. Nevertheless, it feels to me like it's just a matter of taste.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Let's take an Activity class for example, i've seen that many developers use a private variable within the class itself to store a pointer for a widget and they initialize them onCreate event. What is the porpoise for doing that? Isn't that resource wasting by allocating a new variable that we don't really need? I mean, we can always get the object by calling findviewById and, in any case, storing it into a method variable when needed..
If there are many instances of that view being used, code becomes more readable with a variable.
Also, it's marginally faster that looking it up on every usage, especially if there's a lot of usage. Even assuming the best search algorithm, findViewById() takes longer than variable access.
It's a microoptimization anyway; both the memory hit from an extra variable and the lookup time for find are so miniscule, the user won't notice the difference. The time a coder spends on overthinking such matters can probably be better spent elsewhere.
If you have lots of calls to findViewById(), that's a lot of different places where a typo could mean you're getting the wrong view back. By putting the view into a field once, you ensure that you've only got one bit of code to get right. Don't Repeat Yourself.
Conversely, though, you need to make sure that you don't try to access the field before your code has had a chance to initialise it. This isn't usually a problem in practice, but I tend to prefer to make my classes as immutable as possible and not being able to initialise a field until some time after the constructor returns rankles.