define a set of constant
a
I would like to define a set of constants and these constant will be used as
the input of the method.
public Interface MesgConst
{
public final static String str1="This is string 1";
public final static String str2="This is string 2";
}
The following is the method
public void method(MesgConst _val)
{
}
The usage of the constant,
obj.method(MesgConst.str1)
The point for doing this is to limit the options for the user to input when
calling the method.
It is very similiar to HasHorizontalAlignment and
HasHorizontalAlignment.HorizontalAlignment, but I dont understand how it
works.
Can anyone tell me how to do it please?
Thanks
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Arne Vajhøj
> I would like to define a set of constants and these constant will be used as
> the input of the method.
>
> public Interface MesgConst
> {
> public final static String str1="This is string 1";
> public final static String str2="This is string 2";
> }
>
> The following is the method
> public void method(MesgConst _val)
> {
> }
>
> The usage of the constant,
> obj.method(MesgConst.str1)
>
> The point for doing this is to limit the options for the user to input when
> calling the method.
> It is very similiar to HasHorizontalAlignment and
> HasHorizontalAlignment.HorizontalAlignment, but I dont understand how it
> works.
>
> Can anyone tell me how to do it please?
Can you use enum?
Arne
Lew
>> I would like to define a set of constants and these constant will be used as
>> the input of the method.
>
>> public Interface MesgConst
>
You can afford the extra typing to make the class name readable.
Use of interfaces to define constants is an antipattern, labeled the
Constant Interface Antipattern by Josh Bloch and others. Don't do
that. Interfaces are to define types. Anyway, Arne is right - you
want an enum, not an interface.
>> {
>> public final static String str1="This is string 1";
>> public final static String str2="This is string 2";
>> }
>
>> The following is the method
>> public void method(MesgConst _val)
>
Don't use underscores in the names of non-constant variables.
>> {
>> }
>
>> The usage of the constant,
>> obj.method(MesgConst.str1)
>
>> The point for doing this is to limit the options for the user to input when
>> calling the method.
>
With an enum, you can include the method in the enum itself.
Naturally it won't take an argument because the enum class instance is
the implicit first ("this") argument of an instance method.
>> It is very similiar to HasHorizontalAlignment and
>> HasHorizontalAlignment.HorizontalAlignment, but I dont understand how it
>> works.
>
Arne Vajhøj wrote:
> Can you use enum?
>
He should.
--
Lew
markspace
> The point for doing this is to limit the options for the user to input when
> calling the method.
> It is very similiar to HasHorizontalAlignment and
> HasHorizontalAlignment.HorizontalAlignment, but I dont understand how it
> works.
They really don't work.
SwingConstants just holds a bunch of ints. You example just uses
Strings. Neither one of these by their nature actually limits the
options for user of the method. It was a dumb idea for Swing to do
things this way.
It's better to use a specific type that you created to limit the options
for the user of the method.
public class MyOptions {
public static final MyOption OPTION1 = new MyOption( "Option 1" );
public static final MyOption OPTION2 = new MyOption( "Option 2" );
private final String option;
private MyOption( String s ) {
option = s;
}
public String toString() {
return option;
}
}
is the basic pattern. Note the public (but final) static fields and the
private constructor. Those are key. Enums will do some of this
auto-magically for you.
Now you can restrict a method parameter to just OPTION1 or OPTION2.
public void someMethod( MyOptions opt ) {
...
}
Since only you have control of your type MyOptions class, only you can
add more fields for a user to pass to someMethod().
Daniel Pitts
public enum MyOption {
FIRST_OPTION,
SECOND_OPTION
}
public class SomeOtherClass {
public void method(MyOption option) {
//...
}
}
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Lew
> More specifically, he should use a MyOption enum instead:
>
> public enum MyOption {
> FIRST_OPTION
("first friendly display")
{
@Override public void doSomething()
{
// FIRST_OPTION version
}
},
> SECOND_OPTION
("second friendly display")
{
@Override public void doSomething()
{
// SECOND_OPTION version
}
},
;
private final String represen;
/**
* Constructor with String representation.
* @param rep String representation.
*/
MyOption( String rep )
{
this.represen = rep;
}
/**
* Obtain String representation.
* @return String representation.
*/
@Override public final String toString()
{
return this.represen;
}
/**
* Obtain ${type_name} value from String representation.
* @param rep String representation to convert.
* @return ${type_name} value matching argument, or {@code null} if
none.
*/
public static MyOption fromString( final String rep )
{
if ( rep == null )
{
return null;
}
for ( final ${type_name} val : values() )
{
if ( rep.equals( val.toString() ) )
{
return val;
}
}
return valueOf( rep );
}
/** Utility method performed by an enum instance
*/
abstract public void doSomething();
> }
>
> public class SomeOtherClass {
> public void method(MyOption option) {
> //...
> }}
>
--
Lew
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>SwingConstants just holds a bunch of ints. You example just uses
>Strings. Neither one of these by their nature actually limits the
>options for user of the method. It was a dumb idea for Swing to do
>things this way.
Swing and AWT were written before enums existed. Enums were invented
when the disadvantages of AWT and Swing numeric codes became pressing.
Java never goes back and changes old APIs, so you are stuck with those
ints in Swing and AWT. If they were to go back in time, they might
have added enums early and used them in AWT and Swing.
O.P. did not provide much of a clue as to what he is really trying to
do. A static final String[] might suffice.
--
Roedy Green Canadian Mind Products
http://mindprod.com
You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.
Lew
>> SwingConstants just holds a bunch of ints. You example just uses
>> Strings. Neither one of these by their nature actually limits the
>> options for user of the method. It was a dumb idea for Swing to do
>> things this way.
Roedy Green wrote:
> Swing and AWT were written before enums existed. Enums were invented
> when the disadvantages of AWT and Swing numeric codes became pressing.
> Java never goes back and changes old APIs, so you are stuck with those
> ints in Swing and AWT. If they were to go back in time, they might
> have added enums early and used them in AWT and Swing.
They didn't need enums to write static final instances, i.e., "type-safe
enumerations", which have existed since the beginning of Java and have been
widely documented for at least nine years now. Enums are syntactic sugar for
the most common use cases of type-safe enumerations.
But like any project in the beginning, they hadn't thought all that through
then.
> O.P. did not provide much of a clue as to what he is really trying to
> do. A static final String[] might suffice.
A static final String[] is still mutable and not a compile-time constant.
You're right, it might suffice, but it isn't the real deal.
--
Lew