Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I’m learning Java and have recently started my first project. The idea of this project is to pass one input argument - path to file/folder, which would be analyzed in order to find all files with predefined extension, parse them and create objects based on the results of parsing to store for future.
So far I’ve written all the code and my project structure (simplified) looks like that:
Class defining resulting object
Class that analyzes the input parameter (exists, is file, is folder) and processes it, returning list of all suitable files
Class that parses suitable files and creates objects
The question is - am I following OOP with that structure?
From what I’ve read on the web the last two classes seem to look like polterheists. But I don’t think that it is a good idea to move the logic of the third class to the object class because it consists of lots of methods (define current section of the file, strategy to parse each separate section).
I am learning on my own and don’t want to start my journey by cultivating bad habits.
I am learning on my own and don’t want to start my journey by cultivating bad habits.
You're saying this like you have a choice :)
From what you described it seems reasonable, of course w/o seeing the code we can't say. And even if you show the code - 100 people will have 100 opinions, there's a lot of debates around OOP.
What's important is not to look at your design as something static. Once your app starts to be more complicated you'll have to re-work some of it.
PS: stackoverflow doesn't like this kind of questions since everyone will have an opinion. You'll have to find other resources if you keep having such questions.
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 7 years ago.
Improve this question
I recently started a project in Java, that contains a class called System. This class (Luckily) contains methods for output management, so in the rare cases where I need to use the System. methods (Or the System object in general) I just reference it as java.lang.System.. I believe that this could be looked down upon, as System could be looked at as a reserved name. I currently am in the beginning stages of this program, and could change it accordingly quickly, as there are little calls to the class itself.
While it's not illegal, you don't want to do this. If I were the next person working on your code, the first thing I would do is try to remove "java.lang" from "java.lang.System" and then get miffed when it wouldn't compile.
The idea is to go toward brevity and only write what you need to write, while making sense of it all for the next person. It's more an art than a science.
You could always name it something like ProjectnamehereSystem or OutputManager or something to that effect.
I would not create something so similarly named as an important class. While everything is easy to edit, you may be able to keep up with all the changes you are making.
But when the project evolves things will get messy and complex. I would suggest naming it something else that can be easily distinguished.
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 8 years ago.
Improve this question
my main.java file has a length of about 1000 lines. My code is getting more and more confused, and I would like to "split" it in different parts (e.g. in one file I would have essential stuff like OnCreate, in another file I would have for instance GetHttpRequest).
I already tried to put GetHttpRequest in a different class, but is there no simpler way? (It would take a really long time to adjust the code if I used this method)
You have to use classes and methods, and optionally packages.
This will solve your problem. There's no simpler way than that.
Please do not hard-code your program. There are several patterns on how to code a program, so it is efficient, everybody can easily read and understand it. I think you also have a "GUI", assuming to this, I recommend you to use the MVC pattern. It means Model-View-Controller, so you organize your program in Packages: "model", "view", "controller" and in those packages you put the classes. For instance, you have a simple Calculator. Then you have a class in view thats called "CalculatorView", where your graphical interface is and in controller you have your "CalculatorController" that works out the things like calculations. (You call the controller from the view) and you do not need model at all.
I hope that helps you. But you will have to rewrite all your code...
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 8 years ago.
Improve this question
So I've been giving a project for school and was just hoping for reassurance towards the decision making I do.
My java skills are extremely basic and need to improve drastically soon! I just seem to be getting nowhere atm :P
Anyway, back on topic.
My first task is to create an interface directory that can do the following
Keep in mind this is assessed work therefore please don't provide answers. I have enough time to complete this since I've started early!
My initial approach for going about this task is using a Linked List. I don't know what you guys think about that? I may be completely wrong but based on the topics we have covered in School. LinkedList definitely seems suitable. I can add, get and remove.
Cheers for reading guys!
You are along the right lines. The java.util.Collections package will contain most of what you need.
I would actually use an ArrayList rather than a LinkedList as it is faster for random access and sorting.
However note that it says you should be able to find people efficiently and look them up by name.
That suggests using something like a TreeMap structure, mapping name to a class containing information on each person. Store the names as "Surname, Forename" and they will be sorted correctly.
That will only allow lookups based on the complete and correct name though. If you want to search for partial names the map is less useful.
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.