static properties/mutators

1 view
Skip to first unread message

Sergey Mirvoda

unread,
Nov 19, 2010, 3:45:04 PM11/19/10
to lucer...@googlegroups.com
my part of work contains a number of static properties.

for example.
All comparers contains getDefault static method to return default implementation.
Similarity also contains such method.
It is a important part to provide defaults.

But as we all know interfaces couldn't conyains static members. 

How it should be done?

now I simply removing static keyword with Note: comment

--
--Regards, Sergey Mirvoda

Troy Howard

unread,
Nov 19, 2010, 4:10:33 PM11/19/10
to lucer...@googlegroups.com
We will need these for implementation but do not include them in the
interfaces. Interfaces should be instance level only.

We can start implementing some static helpers in lucere.toolkit, but
I'd prefer to refactor out the dependency on static behaviour, moving
as much as possible into instance level members.

Thanks,
Troy

> --
> You received this message because you are subscribed to the Google Groups
> "Lucere Development" group.
> To post to this group, send email to lucer...@googlegroups.com.
> To unsubscribe from this group, send email to
> lucere-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/lucere-dev?hl=en.
>

Sergey Mirvoda

unread,
Nov 19, 2010, 4:12:24 PM11/19/10
to lucer...@googlegroups.com
the problem is.
Seems like All default behavior implemented in Lucene via static getters/mutators
--
--Regards, Sergey Mirvoda

Digy

unread,
Nov 19, 2010, 6:21:21 PM11/19/10
to lucer...@googlegroups.com

Hi Troy,

Just out of curiosity, how do you define interfaces for such a class like below? (since Lucene has o lof of these kind of classes).

Is it enough just defining the "Name"? If yes, doesn’t it mean that a lof of information is lost and you have to rework that class while implementing?

 

I just want to understand the details of your methodology.

 

DIGY

           

      public class MyColor

      {

            private string _Name = "";

 

            public static MyColor Red = new MyColor("red");

            public static MyColor Blue = new MyColor("blue");

 

            private MyColor(string name)

            {

                  _Name = name;

            }

 

            public string Name

            {

                  get { return _Name; }

            }

 

            public static MyColor GetDefaultColor()

            {

                  return Blue;

Troy Howard

unread,
Nov 19, 2010, 7:10:18 PM11/19/10
to lucer...@googlegroups.com
Yes, that is correct. We would only implement Name. The static methods
and values will be be present in the implemented types.

Generally speaking, when we refactor the API, we will try to remove
the need for constant and static values to be exposed in that manner.
The use of such values should be encapsulated inside the behaviour of
the class and not be a required extra step for a class to function
correctly.

Thanks,
Troy

Digy

unread,
Nov 19, 2010, 7:55:51 PM11/19/10
to lucer...@googlegroups.com
Ok. I see.

> Generally speaking, when we refactor the API, we will try to remove
> the need for constant and static values to be exposed in that manner.

Just to remind:
MyColor red = MyColor.Red;
Serialize(stream,red);
MyColor red2 = Deserialize(stream);
Even after that process
red.Equals(red2) should return true.

DIGY

Troy Howard

unread,
Nov 19, 2010, 7:58:08 PM11/19/10
to lucer...@googlegroups.com
That makes sense.

We will build that check into the unit tests for anything marked Serializable.

Thanks,
Troy

Reply all
Reply to author
Forward
0 new messages