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.
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
Lets say I have class Report and I want to add a functionality printReport(...) and shouldBePrinted(...). Printing it requires GeneralPrinter and LanguageTranslator which are given from outside. Furthermore, I should add members to make the shouldBePrintable method more optimized.
The way I see it there are three ways of doing it:
The simplest is to just add the members and functions to the Report class.
Create PrintableReport which extends Report and adds those members and functions.
Use the decorator pattern to add the needed functionality. (Not sure about that one. Please correct me if this is not the correct way to use a decorator.)
Am I missing some and which is the correct method to do it?
Consider: Separation of concerns
At a HIGH level...
While it's not clear exactly what role Report fills, one might surmise it represents information organized in some fashion.
Rendering is a separate concern. Often you'll want multiple ways to render: Generate PDF, HTML, XML, and/or print (postscript, other...).
So, perhaps you have multiple classes to work with Report, GeneralPrinter, ReportPrinter, ...
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.
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 2 years ago.
Improve this question
I'm working on a project where several classes have the same error checking in one of their methods. Should I extract this error checking into a different class, even though it's only under 10 lines of code?
As an example, the method in all the classes take in the same object and does something different with it, I'm checking initially if that object is null and then getting a list from the object to see if it's empty. I was thinking of extracting these checks because I've heard each method should only do one thing.
As a general rule of thumb, you should always extract identical functionality in your codebase and reuse them instead of copying & pasting over. If you have to change the validation logic you'll have to do a shotgun surgery if it is appearing in multiple methods.
There are some battle-tested open-source libraries available for null checking and determining if collections are empty. Look around before implementing your own. Here is an example from the Guava library.
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
This is more of a conceptual question than technical pertaining to Java. I've noticed lately programmers tend to avoid creating classes to pass data around and simply move it using JSONObject if available or a basic HashMap. A lot of new interviewees choose to use what I call a JavaScript method of coding. So instead of creating class called Address, they would store it all in JSONObject/HashMap and pass it around as Object later casting to appropriate type. Also I notice a lot of
try { ... }
finally { return str; }
structured methods.
Is this something normal and accepted these days? To me, it just goes against everything I was thought in school. I mean, no generalization, no encapsulation, etc... And when asked, they claim JSONObject is encapsulation. Well, not disagreeing, but just not something expected.
The task is always being done in the end, but the way its done is disturbing to me. This kind of practice produces a lot of loose structures with a lot of potential errors if programmers are not careful. Wasn't java generics created to avoid exactly that?
Feel free to move this question to other exchange, but I'd really like to hear some opinions from seasoned folks.