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 9 years ago.
Improve this question
Im new to Java, so i hope you guys will teach me a thing or two. Here we go:
1)Why would i use constructors? I got so many issues with contructors, because i dont know why and how to apply them and i really need practice, before i fully can understand it.
2)How would your constructor look like, when you got:
2 classes - Vehicles and Car. Car needs access to variables, in the Vehicles class, so i can start working on methods with certain variables(that belongs to Vehicles class), from the Car class. I just need to see some examples.
3)I got this from another question(thanks again, for helping me out):
public Vehicles(Car frame) {
this.testingobj = frame;
}
It works, but why does work and what does it do? I use it on every class i create. It seem like it can contact my Car class, when i press a JButton, to activate a method in Vehciles class. Is there anything i should consider in contrast of question )2?
Thanks for your help and time!
A class definition is like a blueprint. It defines the API for the class and what it can do. But a blueprint is just a blueprint. It isn't useful until you actually have something to work with. It's nice to read all the specs on a Bentley; it is even nicer to see one and drive it.
This is where a constructor comes in. It creates a new instance of the class by reserving space in memory for it and initializing it so that it is in a proper state ready to do all the things its class definition promises its clients it can do.
As for your example, I think you need to understand object-oriented design before you worry about the mechanics of constructors. Why would Car need to access a Vehicle? A car is a vehicle.
You need to think about what you are trying to accomplish and understand how objects work together to get things done. Then you can worry about constructors and ultimately Android development.
Related
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 6 years ago.
Improve this question
Question might be silly for experts but please help me with pointers if it is already solved somewhere.
Interview Question : "Design class diagram in best possible way"
You need to design a game "SuperHeroes".
Super hero examples are Batman, Spider-Man, Thor, Hal Jordan, Wonder Woman, Captain America .... n
Spiderman can jump, crawl, generateFire ....n
Batman can jump, crawl, fly .... n
Thor can swim, fly .... n
There can be millions of behaviour.
There can be millions of Super heroes.
Some have few behaviours common in them and some specific to hero.
Design should be flexible enough to add behaviours to the super heroes
Important point to focus was told that "System should be scalable"
I tried twisting decorator pattern to accommodate problem requirements but was failing at many places, also I have to make many interfaces for this, so scalability was questionable.
I tried another approach as Writing all behaviours in one class(If require will classify behaviours in respective classes, kind of utility class which will have all implementations of behaviours). and an Spiderman class which will have list of allowable Behaviours(kind of enum). and it is allowed to call methods from behaviour utility only if such behaviour is allowed in list. I think it is not a good approach.
Please help me with best way to achieve this.
If I understood the question correctly, the problem could be solved with the mixin pattern; however, multiple inheritance is required for a straightforward implementation, which is not available in Java. The subject is discussed in this question.
In games it is pretty easy to get a very huge inheritance tree up to the point, where it is very difficult, if not impossible to add a new entity with a different behaviour. To solve this, something called the Entity Component System is used. It is very flexible, does not limit you to inheritance and is commonly used in larger games.
There is also a follow-up article that describes a specific implementation, and has examples on how it can be used in different situations.
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 6 years ago.
Improve this question
I'm working on what's basically my first GUI program in Java and it's been working well for me so far. Everything runs smoothly, however I want to make sure I use and understand solid programming principles.
For my GUI class I have about 300 lines of code (which I've come to understand is pretty small). I've been using SWT and this GUI one window for now. I have four tab items that each contain a different set of widgets for use. I intend on having a class for each tab to take care of their respective back end requirements.
As I've searched existing questions I've found the Single responsibility principle referenced on several occasions. To my understanding, one window per class would fit this principle. When (if ever) would I break a GUI into multiple classes outside of multiple windows?
Design principle are guidelines for writing good code. Single responsibility principle says we should have only single source of change for a class.
How do we know what is the source of change in a class ?
What can change in a class ?
Answers to these questions lies with the team directly in touch with the end users. For this it is important to reach to the team interacting with the client as soon as possible with a basic simple design. It is quite obvious , we will be asked to add more new features or add new requirements.
The process above will let us know what is the set of responsibilities that our class is performing is changing. We must put those set of behaviors in separate class(s). Now our existing class should communicate with the newly created classes via. Abstractions. This is dependency inversion. Now our class no longer is dependent upon the entities which change or which can potentially change with high probability. In the abstractions only the behaviors needed by the our old class are put. Implementation details are put in newly created concrete classes which extend the Abstraction class we have created.
From the very beginning, trying to figure out all the responsibilities and putting them in separate classes even when (they may never possibly change) will make the code scattered.
Large classes are verbose. They are not browsable, they have high risk of getting affected with changes un intentionally.
Regarding your specific question on when you would want to break out stuff into a separate class:
Let's assume you write an address book. You would probably want to present a contact's details in various places of the application. Or present multiple contacts at once. This would be accomplished by writing a separate class, like ContactDetailsPanel.
In general, most of the usual patterns apply to GUI classes as well: don't repeat yourself, single responsibility, and so on. One pattern I would like to point out when writing GUI code is MVC: Model-View-Controller. It's basically about separating business logic, presentation, and data.
You might want to take a look at what kind of things get separate classes in SWT, too.
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 7 years ago.
Improve this question
I'm using Java to do some complicated calculations, and have a lot of classes that need access to a lot of the same variables. These variables are set at different stages of the calculations, in different classes. The problem is that my code is getting quite messy as I am being forced to pass the same parameters to a lot of different methods.
I am looking for peoples thoughts on what the best approach here would be? One idea I have is to make a superclass with all these variables set in it and extend this class everywhere it is needed.
Another option is to pass an object holding all this information around from method to method but this seems overly complex.
Neither of these solutions feel like the cleanest approach to me. Any thoughts or suggestions of design patterns/ideas that may help me are appreciated. Thanks for your help.
I'm going to suggest that using a Wrapper object is the best way to do this. Make sure all fields are immutable (final keyword in Java). Use a Builder or Prototype pattern to create new objects to return.
How about using a Singleton? That way you'd have global access to it without passing any instances around and all the variables will be under one roof reducing messiness.
I would recommand to separate the problem world (i.e. the variables) from the algorithms (i.e. calculations) in separate classes. The algorithms would get passed in the problem world, and modify it accordingly. This can be seen as an implementation of the Visitor Pattern.
Depending on the complexity (number of variables, number of algorithms, uncernity of solution path), you could also implement a Black Board Architecture. But I think that would be an overkill, if you're not doing something in artificial intelligence...
If there are a lot of values to be passed around, perhaps an in-memory database would be an appropriate solution. A lot of databases these days offer an in-memory engine, e.g. MariaDB.
Make a superclass of subclasses then refer to those subclasses of the superclass everytime you need to pull information
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 currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.
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 9 years ago.
Improve this question
i have been reading about this topic , and the more i read the more confused i get ,
can somebody please elaborate , we were using language C which follows structural approach ,
so what was wrong with this approach , that we moved to create a object oriented language JAVA .
I have been reading so many theoretical aspects , can some body please give more of a few practical illustrations ,
WHY WE NEEDED OBJECT ORIENTED APPROACH IN THE FIRST PLACE
I am not looking for an answer to be given in any interview or tutorial
I am looking for an answer to get the better understanding/practical importance of object oriented aproach
There are many explanations regarding this. But I would like to refer this
Modularity: The source code for a class can be written and maintained independently of the source code for other classes. Once
created, an object can be easily passed around inside the system.
Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from
the outside world.
Code re-use: If a class already exists, you can use objects from that class in your program. This allows programmers to
implement/test/debug complex, task-specific objects, which you can
then use in your own code.
Easy Debugging: If a particular object turns out to be a problem, you can simply remove it from your application and plug in a
different object as its replacement. This is analogous to fixing
mechanical problems in the real world. If a bolt breaks, you replace
it, not the entire machine.