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.
>
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;
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
> 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
We will build that check into the unit tests for anything marked Serializable.
Thanks,
Troy