From: Lew on
Rhino wrote:
> Am I correct in assuming that a valid example of 'state' is the Locale
> used by the class/methods to generate error messages?

If the locale is maintained between calls, then its part of the object
state. If it's only used as a method parameter, then it's not part of
the object state but just the current invocation.

> My StringUtils class generates a substantial number of error messages
> via the standard ResourceBundle mechanism and delivers them in a
> Locale-sensitive fashion. I have two constructors for StringUtils, one
> that has no parameters and simply uses the default Locale, and the
> other, which has the Locale desired by the user as the single
> parameter.

If you have a meaningful constructor, you have left static-land and
are now committed to instance-land. If you are building a utility
class, everything must be static. If you are building a helper class,
then make it instantiable and don't use static methods.

> Now, if I want to continue to deliver Locale-sensitive messages and if
> I make the constructors private, I can't tell the methods which Locale
> to use in selecting message files via the constructor. I suppose I
> could add a Locale parameter to each method's parameter list but that
> seems ugly.

"Ugly"? "Ugly"? What is that supposed to mean?

If you are making a utility class with all static methods, you need to
pass the Locale as an argument.

If you are making a helper class with instance methods, then by all
means use the constructors to initialize a private final variable for
Locale.

> What's the best way to handle Locale-sensitive messages if I want to
> keep my methods static and my constructors private?

Pass the Locale as a method argument.

Remember, the utility class with all static methods must have only
class-level state, not instance-level.

"State" is a standard term; it refers to the current values of
variables associated with the instance.

You can have 'static' state, that is, state maintained by class
variables as opposed to instance variables. The state is associated
with the class as such, and thus does not hurt your staticness.

Static state risks thread issues; the safest thing for static state is
that it be immutable where it exists at all.

> Or does this factor change everything and now justify keeping the
> StringUtils constructors public and its methods non-static?

Since your analysis indicates that you need multiple instances of your
'StringUtil' class, each with different behaviors, you have answered
your own question.

--
Lew

From: Lew on
Rhino wrote:
>>> I have a class named StringUtils containing several utility methods.

markspace wrote:
>> I asked aquestionlike this here long ago.  What I think now is that
>> you almost certainly should make the class final, and all the methods
>> static.
>>
>> If you do need to keep state, make a new class, don't reuse the
>> StringUtils, except as a factory.

Rhino wrote:
> Sorry, I'm not following this strategy.
>
> I'm not entirely sure what constitutes 'state' in this context but I

Same thing it means in any other context - "state" is the aggregation
of the observable aspects of the (class or instance) object, i.e., the
values of its attributes, in particular, those that affect its
behavior.

markspace is telling you that if you write a class to be stateless,
then need to add state, it's not a good idea to mingle state with a
stateless class. You're better off separating the behaviors into a
stateless class and a stateful one.

> suspect that the Locale-specific messages I am generating may qualify.

Depends on how you do it - if you store the Locale as part of the
state, then yes, it affects things.

> As I've explained in my reply to Lew's first response, I am generating
> Locale-sensitive error messages. I have two constructors. One

Constructors means no longer being all static.

> constructor has no parameters and uses the default Locale; the other
> constructor has the Locale as its parameter and generates messages
> appropriate for that Locale. If this counts as "state" for the

Is it an observable attribute of the object?

Does its value affect the object's behavior in any way?

Does the value persist between method calls?

> purposes of our current discussion, I'm not clear on what you're

State is state, purpose notwithstanding.

> proposing. How do I use StringUtils as a factory to feed the new class
> that you are suggesting?

You add a factory method to create an instance of the stateful class.

--
Lew
From: Lew on
Rhino wrote:
>> I'm not entirely sure what constitutes 'state' in this context but I
>

markspace wrote:
> It basically means "an instance variable."
>

Unless you're talking about a static variable. That's state, too.

The former is instance state. The latter is class state, or "static"
state.

--
Lew
From: Rhino on
On Mar 16, 1:02 pm, markspace <nos...(a)nowhere.com> wrote:
> I'm quoting your entire message below since a lot of folks here filter
> Google groups.
>
> Short answer:  If you're creating a class with instance variables,
> that's "state" and you should not be using static methods.  Basically,
> since you left out this important detail, all the advice you got on this
> thread is wrong.

Yeah, sorry about that omission. I didn't take the Locale issue into
effect when I asked the original question, then my news server issue
prevented me posting until now.
>
> Yes, a class that needs constructors for arguments/initialization needs
> public constructors.
>
>    public class StringUtils {
>      private Locale locale;
>      public StringUtils( Locale l ) {
>        locale = l;
>      }
>      public String count( String dup, int count ) {
>        ...
>      }
>      ...
>    }
>
> Note now I'm avoiding the static keyword everywhere.
>
And that's how the code was when I posted the original question....

> Rhino wrote:
> >> A class who will never have instances with their own state, whose sole
> >> purpose is to provide utility methods for other classes, whose entire
> >> operation depends only on data in the argument lists of those methods,
> >> and ultimately, for whom it really never adds value to have an
> >> instance, is called a "utility class" and likely should have
> >> instantiation prevented and all its members static.
>
> >> Declaring a class final does not prevent its instantiation.  Declaring
> >> its constructor private does, and also prevents subclassing, making
> >> the 'final' declaration redundant, so don't bother with it.
>
> > I've read all the replies to this thread and have been trying to post
> > followup questions since yesterday afternoon; unfortunately, I've had
> > major problems with the news server and have finally had to resort to
> > posting via Google groups. Sorry for the delay!
>
> > --
> > Am I correct in assuming that a valid example of 'state' is the Locale
> > used by the class/methods to generate error messages?
>
> > My StringUtils class generates a substantial number of error messages
> > via the standard ResourceBundle mechanism and delivers them in a
> > Locale-sensitive fashion. I have two constructors for StringUtils, one
> > that has no parameters and simply uses the default Locale, and the
> > other, which has the Locale desired by the user as the single
> > parameter.
>
> > Now, if I want to continue to deliver Locale-sensitive messages and if
> > I make the constructors private, I can't tell the methods which Locale
> > to use in selecting message files via the constructor. I suppose I
> > could add a Locale parameter to each method's parameter list but that
> > seems ugly.
>
> > What's the best way to handle Locale-sensitive messages if I want to
> > keep my methods static and my constructors private?
>
> > Or does this factor change everything and now justify keeping the
> > StringUtils constructors public and its methods non-static?
>
> > --
> > Rhino
>
>

From: Rhino on
On Mar 16, 1:06 pm, Lew <l...(a)lewscanon.com> wrote:
> Rhino wrote:
> > Am I correct in assuming that a valid example of 'state' is the Locale
> > used by the class/methods to generate error messages?
>
> If the locale is maintained between calls, then its part of the object
> state.  If it's only used as a method parameter, then it's not part of
> the object state but just the current invocation.
>
> > My StringUtils class generates a substantial number of error messages
> > via the standard ResourceBundle mechanism and delivers them in a
> > Locale-sensitive fashion. I have two constructors for StringUtils, one
> > that has no parameters and simply uses the default Locale, and the
> > other, which has the Locale desired by the user as the single
> > parameter.
>
> If you have a meaningful constructor, you have left static-land and
> are now committed to instance-land.  If you are building a utility
> class, everything must be static.  If you are building a helper class,
> then make it instantiable and don't use static methods.
>
> > Now, if I want to continue to deliver Locale-sensitive messages and if
> > I make the constructors private, I can't tell the methods which Locale
> > to use in selecting message files via the constructor. I suppose I
> > could add a Locale parameter to each method's parameter list but that
> > seems ugly.
>
> "Ugly"?  "Ugly"?  What is that supposed to mean?
>
Sorry, that wasn't very precise phrasing.

If I pass Locale in to each method, then I will need to revise each
method to include a Locale parameter; some versions of some methods
already have 7 parameters, which already seems excessive and 8 is that
much worse. Also, since I'd like to give the user the option of using
the default Locale, then I need two versions of each method, one that
does not specify Locale and uses the default Locale and one that lets
the user specify the Locale. That's what I mean by ugly.

Given that classes in the Java API don't typically use that approach,
I'm assuming this is not an approach that I should adopt either....

> If you are making a utility class with all static methods, you need to
> pass the Locale as an argument.
>
> If you are making a helper class with instance methods, then by all
> means use the constructors to initialize a private final variable for
> Locale.
>
> > What's the best way to handle Locale-sensitive messages if I want to
> > keep my methods static and my constructors private?
>
> Pass the Locale as a method argument.
>
> Remember, the utility class with all static methods must have only
> class-level state, not instance-level.
>
> "State" is a standard term; it refers to the current values of
> variables associated with the instance.
>
> You can have 'static' state, that is, state maintained by class
> variables as opposed to instance variables.  The state is associated
> with the class as such, and thus does not hurt your staticness.
>
> Static state risks thread issues; the safest thing for static state is
> that it be immutable where it exists at all.
>
> > Or does this factor change everything and now justify keeping the
> > StringUtils constructors public and its methods non-static?
>
> Since your analysis indicates that you need multiple instances of your
> 'StringUtil' class, each with different behaviors, you have answered
> your ownquestion.
>
> --
> Lew