4

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.

user2990315
  • 271
  • 1
  • 5
  • 11
  • 1
    When you need them? Or, more correctly, when you don't need (exposed) state. – Hot Licks Dec 30 '13 at 00:55
  • I would say when you need them and when not to have them. If it doesn't have state why should we actually write those. It will be similar to functional programming right? – user2990315 Dec 30 '13 at 01:00
  • (Look at java.lang.Math, for instance: Would it make any sense to have that be a stateful class such that you had to create an instance of Math to calculate a cosine?) – Hot Licks Dec 30 '13 at 01:01
  • You may want to put your static utility methods in a separate class. – PM 77-1 Dec 30 '13 at 01:02
  • (Though it should be observed that if you find yourself creating a lot of stateless classes you probably are not partitioning your working data into classes the way you should.) – Hot Licks Dec 30 '13 at 01:03
  • (One should also observe that "stateless object" is something of an oxymoron. There is no need to create an instance of a stateless class.) – Hot Licks Dec 30 '13 at 01:08
  • 2
    your definition of "stateless object" is wrong: normally "class variable" (or class member) refers to static members. However what you are talking seems to be "instance variable". – Adrian Shum Dec 30 '13 at 01:33
  • I can think of a good reason to have a stateless object: you have a class where it's conceivable someone might want to add some state to it in the future. E.g. you have a class of utility methods, and then at some point someone wants to add a global flag or something that affects the behavior of some of the methods (e.g. a "rounding mode" in a math class). Globals like this should be part of objects. Making a change like this is less disruptive to a large program if the methods already required an object to be instantiated. – ajb Dec 30 '13 at 15:56

2 Answers2

7

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.

fabian
  • 80,457
  • 12
  • 86
  • 114
1

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.

keshlam
  • 7,931
  • 2
  • 19
  • 33
  • That would be immutable but not stateless. A case where you might implement true stateless objects is where you want to pass as a parameter a "behavior", without any associated "state". Eg, you might have a package where you could pass in one of several different sorting behaviors. – Hot Licks Dec 30 '13 at 01:54
  • One can quibble about whether immutable behavior can or can't be considered "state" in any reasonable sense -- "return 0" is not generally considered state -- but I grant your point; that's a better example in any case. – keshlam Dec 30 '13 at 01:58
  • A String is undeniably a stateful object, yet immutable. – Hot Licks Dec 30 '13 at 01:59
  • Granted. Immutability is not enough. Though if you were implementing a version of CharSequence which -- by class design -- always appeared to have the value "Foo", I'd call that stateless since you can't even set it at c'tor time. Hardcoded constant objects are sometimes useful optimizations. We agree that the bundled-behavior object is a better example. – keshlam Dec 30 '13 at 02:05