Using Interfaces as States
4 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Steven_Martin
Posted On:   Tuesday, October 29, 2002 01:01 PM

I've created a interface to represent three states for my status. Here is the code below: public interface SelectedStatus { public SelectedStatus NoneSelectedStatus = new SelectedStatus() { }; public SelectedStatus PartialSelectedStatus = new SelectedStatus() { }; public SelectedStatus AllSelectedStatus = new SelectedStatus() { }; } My question is what are the costs of this will be (performance, development). I don't expect these states to have any functions and it's to have only interface instead of a inheritance hierachy representing state. Instead of using classes I should see a very small performance improvement over state co   More>>

I've created a interface to represent three states for my status. Here is the code below:

			

public interface SelectedStatus {
public SelectedStatus NoneSelectedStatus = new SelectedStatus() {
};
public SelectedStatus PartialSelectedStatus = new SelectedStatus() {
};
public SelectedStatus AllSelectedStatus = new SelectedStatus() {
};
}



My question is what are the costs of this will be (performance, development).

I don't expect these states to have any functions and it's to have only interface instead of a inheritance hierachy representing state.



Instead of using classes I should see a very small performance improvement over state comparsions instead of using strings. I'm also not cutting myself out of other states since I can implement or extend the interface.



thanks,
Steven    <<Less

Re: Using Interfaces as States

Posted By:   Joe_Felchlin  
Posted On:   Friday, December 6, 2002 02:57 AM

I've seen this idiom recommended somewhere else for the purpose of robustness, and I think it has merit. The development advantage is that it is superior to assigning states to static final ints, which can be a bad habit and result in the temptation to do comparisons with literal ints in other places in the code. Imagine what would happen, for example, if the definitions were changed.




As far as performance goes pointer comparisons should have good efficiency. The question is, compared to what. It will beat String comparisons every time (impressively). It will probably be roughly the same as integer comparisons though -- perhaps slightly slower.


Re: Using Interfaces as States

Posted By:   Lance_Walton  
Posted On:   Friday, November 1, 2002 05:55 PM

Hi.

> I don't expect these states to have any functions and it's to have only interface instead of a inheritance hierachy representing state

If you have are enumerating a number of different 'status' values, then something, somewhere in the code cares about that difference (otherwise, why bother with it). Therefore, at the very least, it seems like a good idea to implement the Visitor pattern within this enumeration so that whatever it is that cares can be sure that it has considered every possible status value.

Regards,

Lance

Re: Using Interfaces as States

Posted By:   Anonymous  
Posted On:   Tuesday, October 29, 2002 11:49 PM

Steven, I use this pattern regularly. The big advantage IMO is that you later can move behaviour into the interface/class, making effective use of polymorphism.

Notice, though, that in your case you could even go with a simple class having a private constructor - that way you wouldn't need the anonymous implementations of the interface. If you needed different implementations later, you could easily refactor it to your current solution...

Re: Using Interfaces as States

Posted By:   Christopher_Koenigsberg  
Posted On:   Tuesday, October 29, 2002 02:21 PM

Are you maybe trying for a "typesafe enum" pattern?



?? But your code makes no sense, the way you wrote it here.... If SelectedStatus is an interface, you need to implement it somewhere before you can call a constructor to return an instance of something which implements it. You cannot say "foo = new SelectedStatus()".



You could have 3 classes, "NoneSelectedStatus", "PartialSelectedStatus", and "AllSelectedStatus", all of which could implement the SelectedStatus interface, and you could then assign an instance of each class, to refs all of the common SelectedStatus type. But you can't say "new SelectedStatus()" if SelectedStatus is just an interface?

About | Sitemap | Contact