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
When writing an application(in java) that you intend to open source, is it generally a good idea to have a lot of getters & setters and make variables private? More specifically, if that were to be an android application, would the answer to the question above still hold?
Edit: If you guys could give me a concrete reason as to why its better, that would be awesome.
If you are discussing getters & setters in ANDROID, check what android documentation tell:-
Avoid Internal Getters/Setters
On Android, this is a bad idea. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.
if all the private variables are expected to be accessed from out side then yes.
Suppose you have certain flags those aren't going to be used from outside then no need of getters/setters for those.
Also See
why-use-getters-and-setters
Lets put it this way, you don't feel any need of having getters/setters and you plan to make your properties non-private. It doesn't appear to be any problem with this approach. But you must ask few questions to yourself.
Are you having any property whose value should undergo some checking before assignment? (Need for a setter)
Do you have any mutable property which you don't want to expose as it is? (Need for a getter)
Now, if you think your few properties need getters/setters, but not all. Then I would say create getter/setter for all of them for the sake of consistency. :)
Further see, Effective Java 2nd Edition,
Item 13: Minimize the accessibility of classes and members
Item 14: In public classes, use accessor methods, not public fields
Item 15: Minimize mutability
Item 38: Check parameters for validity
Item 56: Adhere to generally accepted naming conventions
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 3 years ago.
Improve this question
I have a class that has many fields made of objects of other classes. This class is used by multiple people who keep adding more fields to it according to their needs. I want to know if there's a drawback to this compared to having one collection field, say a Hashmap, in this class which can be used to contain other classes as and when necessary. This looks cleaner to me than declaring many fields which might end up not being used
A class with too many fields and methods is certainly harder to grasp and change later on - the shorter the class is, the easier it is to understand its uses.
On the other hand, keeping different class variables inside one hashmap in order to make the class shorter is not a good idea at all because you will lose type safety and will have to add many additional checks and castings later on.
In conclusion you should always keep the classes as simple and clean as possible without sacrificing best coding practices - perhaps instead of having so many different fields in one class you could have multiple smaller classes, each with their own responsibility, instead.
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 7 years ago.
Improve this question
What is the advantage of having static method and default method introduced in java 8 as i found it will add complexity and ambiguity in your code. Please bring some light on this.
The advantages are clear: static methods in the interface allow factories such as Stream.of to be placed right where they belong. Previously you would need a StreamUtil class or similar to hold them. Defender methods ("default") were an absolute must in order to introduce Stream-oriented goodness all around the Collections API, and are a very useful feature on their own, allowing free growth of API with convenience methods which only rely on other methods of the public API.
No complexity or ambiguity is added to your code, especially since the static methods are not inheritable.
The biggest adavantage of having default methods is that you can evolve an API for new features even it was already released without breaking the implementation of the users of the API.
Static methods make it possible to dispense with utility classes as the implementation can be written in the interface.
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'm new to Java, and get really confused about deep copy.
I think each method that takes some mutable objects as arguments and returns an object that is related to the input should make defensive copy. However, after some coding I find this is very tricky.
For example, I want to choose some objects from a container satisfying some conditions, and returns them as a smaller container:
List<SomeType> chooseWithSomeCondition(List<SomeType> input)
But SomeType is defined by others, which is not immutable, not clonable, not serializable, neither has any copy constructor. Since Java's final cannot help either, I don't know how to make deep copy here.
Is my criteria too strict? Is the code I've read problematic? Are there some other ways to make deep copy? Please share your thoughts, and thanks in advance.
In this particular case, the code is problematic, and I'd just do a shallow copy. In your docs, note that the method is actually "chooseWithSomeConditionAtThisInstant" and tell others NOT to modify the elements of either list, or to do so with care and thought. (There are use cases where you want changes to come through.)
In the case of a type where you cannot use normal copying methods for deep copy (in your case of non-serializable, non-clonable, non-instantiable...), you would need to work around with reflection.
If you think reflection is too slow, or constructors can't be used, then you may want to think about using sun.misc.Unsafe to instantiate.
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
Like in Scala? Is there any pattern in Java to avoid having all the boilerplate setter/getter without using 3rd party jars? Thanks
update:
my aim is to avoid having too many ghost methods for Dtos, thanks
If all you want is to avoid having to type, use auto generation feature of IDEs like some others mentioned.
If you want to avoid seeing getter/setter in your classes, use a library called lombok which can generate the getters/setters behind the scene
If the above options are not OK for you and you need to set the value only once, you can declare all your fields as public final and have a constructor setting the values.
CAUTION: I am not suggesting this third option as a good practice as it breaks the Javabeans convention. Also it exposes your class' internal structure, but honestly, even with prolific use of getters, you are exposing class fields to the client.
There are a lot of IDE's out there for java that will help you with this problem.
In Eclipse, when you right click on a variable, you can choose Source -> Generate Getters and Setters.
I never used Scala but this should do.
in idea intellij u can create as AlT+ insert and then choose getter+setter