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
This is my understanding about stateless objects:Any object created from class that doesn't have class variables is a stateless object.
My question is when should we write stateless classes. Is it a good habit to have stateless objects.
Stateless objects are useful if you need to "pass functionality as a parameter". Since functions are no Objects in java, it's a practical way to pass the an object with the function as parameter.
For example Comparators can be used to sort, if a class does not implement Comparable or if you need to support sorting with different definitions of the "<"-relation. (e.g. accending / descending order; sorting by different properties ...)
A factory (see http://www.oodesign.com/factory-pattern.html) may be a stateless object. All functions of the factory may create objects and all parameters necessary to create
them can be given as parameters of the functions of the factory.
Generally, if what you have is stateless (has no instance variables, only class variables), it has no reason to ever be instantiated and shouldn't be an Object (though implementing it as a class can be useful to group related functionality together and to manage access to the static class variables).
The one case where a stateless object is justified, in my opinion, is when it's a trivial implementation of an interface. For example, an immutable Collection (eg an EmptyCollection) may want to be an object so it can be passed around and manipulated like other Collection objects, but can be implemented as stateless since it's immutable and its state can never be changed.
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
In order to obtain the hash code of an object in Java, we use the hashCode() method.
To access (private) fields in Java, by standard, we are expected to have separate method with get or set as prefixes based on the kind of operation the method is performing. So why is this different for the hashCode method?
The method hashCode() has been introduced with the first Java version, i.e. officially version 1.0.
The getXXX() and setXXX() paradigm was established later as part of the JavaBeans standard. JavaBeans defines a simple yet very useful component model by deriving properties from pairs of getters/setters. JavaBeans was introduced with JDK 1.1.
So hashCode() predates the getter/setter paradigm.
In the end: conflicting paradigms.
Keep in mind that methods such as hashCode() are with java since day 0 more or less. And back then, there wasn't an established standard suggesting: use getters resp. an explicit "methods should be named doWhatever()".
And once released, renaming it to a more appropriate computeHashcode() or something alike would have broken all existing source code.
In other words: there is also a mindset of using very short method names, such as size() in the Collections 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 4 years ago.
Improve this question
I did some research but didn't find an answer that I am looking for. In Spring, DAO and service classes are declared as interface. Classes implementing interfaces are usually singleton Java beans. Question: do you see any reason that I should make private methods that don’t rely on instance variables static? Why?
For example, I have several private methods in a DAO class converting database data to domain object and these private methods don’t use instance variables. I understand some people might suggest that I should extract them to a utility.
The word singleton is used in multiple ways, which can cause a bit of confusion. A "hard" (physical, class-based, JVM) singleton is a class that ensures that only one instance can exist in the entire JVM, usually through an enum or a constant. This pattern should be avoided if the object has any state or configuration at all, since that can cause unexpected coupling between parts of an application. (It's usually fine if the object represents either a pure function, such as CASE_INSENSITIVE_ORDER, or a value.)
In contrast, a singleton-scoped bean (logical, container-based) simply means that the container that is managing it will keep a single shared instance and supply it to all consumers that want one (instead of, for example, creating a separate private copy for each consumer). In most Spring applications, it's actually preferred for these to implement a Java interface that serves as the contract between the two sides, so the methods can't be static.
As to performance questions, static carries a meaning--specifically, that the method or field doesn't have a relationship to a specific instance of that class. Use it when the meaning is appropriate (such as most of the methods in Math), and don't change the meaning of your code in this way for any theoretical performance reason.
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
Would it be overhead to always return a copy of collection/object field?
Clearly, yes it would be a overhead ... compared with returning a reference or a shallow copy.
But that's not really the point. The real point is whether the overhead is warranted / necessary, and whether it can be avoided by using some other data structure / design / technique. The answer to those questions depends on the context.
Here are some illustrations:
If a target object getter returns an immutable object, a copy is unnecessary. Example, any getter that returns a String.
If a target object getter returns an object that is not part of the target object abstraction, a copy is undesirable. Example list.get(int), Iterator.next().
If a target object getter returns a mutable object (or array) AND the returned object is part of the object's internal state AND the target doesn't necessarily trust the caller, then the getter should either copy it or wrap it ... or there may be a security problem.
The same may apply in non-security-related contexts; e.g. ArrayList.toArray(...) copies the list into an separate array rather than returning the list's backing array. (Similar for getChars() for a String, StringBuffer, etc.) This is all about maintaining the abstraction boundary so that on class won't "break" another one.
If a target object getter returns a mutable object (or array) AND the returned object is part of the object's internal state BUT the target object's API / abstraction boundary is designed to be "porous" (e.g. for performance reasons), then copying may be self defeating.
Of these, 3 is the only case where cloning is strictly mandatory. In 2, 4 and 5 you could argue that it is a matter of how you design the public (or internal) APIs for the classes, libraries, applications. And often there are many viable choices.
It is overhead for sure but there are already some framework classes which do that. It is also described in the book Effective Java.
Remember:
"Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, limit its mutability as much as possible."
When you want to create immutable classes than you can use a framework like that: http://immutables.github.io
For examples check this Oracle documentation
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 8 years ago.
Improve this question
In many places Java utilizes the approach to have both, for example, Collection and Collections class.
Collection is interface, it defined some methods.
Collections class also provide some method.
Why didn't they choose to place all methods inside the interface?
because the names are too puzzled word. Collection is like Collections.
I know the historical reason. like interrupt() and interrupted() , because java must fit to old version, the methods' names are likely, make developer difficult to write and read.
But the collection framwork must have reason in this way.
For starters, an interface cannot have static methods. Note: until Java 8.
Arguably, some of the static methods of Collections should have been made instance methods of Collection, but that would create a lot of "clutter". Plus, extra work for implementations not derived from AbstractCollection etc.
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 4 years ago.
Improve this question
When is it feasible to nest classes?
The most common advantage of it that I see is "shared scope" (use of variables across classes).
Is this less attractive/less a best practice than just putting the nested class in it's own file, and passing the arguments through the Constructor?
There are several reasons for using nested classes, among them:
It is a way of logically grouping classes that are only used in one place.
It increases encapsulation.
Nested classes can lead to more readable and maintainable code.
Child to parent class connection is simpler as it visually illustrates the variables and methods of each class.
In addition to those mentioned already, one other benefit is:
Nested classes also help you achieve multiple implementation inheritance (ref: Thinking in Java, page 369 - section "Why inner classes"?). As far I know, there is no other way to achieve it in Java.
According to me the one case i know when nested classes used, When we see one object(OBJ1) is tightly bind with second object(OBJ2) and we can not create first object (OBJ1) without second object(OBJ2). for an example we have employee object and one associated object is salary and we should not able to create salary object independently. because without employee to whom we are going to give salary.
Provide your feedback if i am wrong.
Second case when we are using map or map then we can use nested classes to remove map of map to make code easy to understandable.
third when we want to send data to client side and we can send it in single object having all data :)
when we need something which can define component of outer class or we want to define adapter.
I find private static classes useful when I need to pass a group of related fields into a method and manipulate the same group of data throughout a few method invocations inside a class. Similar to LinkedList.Node class which is not exposed to outside rather used to group links as a single unit.