koobas.hobune.stream
Question on C# Interface Method Parameters
Hello everyone, I was doing some work in trying to familiarize myself with FMS', and in one of the tutorials I was looking at I saw something similar to:
public interface IState {
//test interface used in a FFSM.
void Update (DummyClass target);
}
Now this was all fine and good, but I was left wondering about 2 things:
1) Is there a way to implement some sort of generic parameters for the method? Something like:
public interface IState {
//test interface used in a FFSM.
void Update (AnyClass anythingIWant);
}
For a case where you either don't know what type you'll end up working with or just want a large variety of types to be useable.
2) Is there a way to overload the parameters? Something like:
public interface IState {
//test interface used in a FFSM.
void Update (DummyClass target);
void Update ();
}
Since each time I add a method, I have to keep adding implementations that may not make any sense in the class that implements them.
Any insights are appreciated, and I apologize if my questions are outright stupid. [Also, anyone else have the TAGS for posts keep disappearing when entering new ones? Really annoying...]
In answer to 1)
What you want is to use a Generic interface, in your case you could have something like:
public interface IState<T> {
//test interface used in a FFS$$anonymous$$.
void Update (T target);
}
2) I don't think I understood this question, if you add Update() to your interface you will have to implement that method as well on your classes.
Thank you very much for the example, as far as the second question goes, I posted a response to VesuvianPrime that hopefully will help clarify what I'm after.
@boddole about the tags, yes it happens - the way I deal with it is that I write a tag (don't use autocomplete) then follow it up with a comma, doesn't disappear.
Yeah, I end up doing that to, I'm just paranoid that I'll type a tag wrong and no one will end up seeing the post.
There are a few different approaches to your first question:
void Update (AbstractDummyClass anythingIWant);
void Update (IDummyClass anythingIWant);
public interface IState<T>
{
void Update(T target);
}
I'm not really sure what you're asking with the second question. You can always overload interface methods in the classes where it makes sense:
public interface IState
{
void Update (DummyClass target);
}
public class MyState
{
public void Update (DummyClass target) {};
public void Update (SomethingElse target) {};
}
You could even chain interfaces:
public interface IState
{
void Update (DummyClass target);
}
public interface ISpecificState : IState
{
void Update (SomethingElse target);
}
public class MyState : ISpecificState
{
public void Update (DummyClass target) {};
public void Update (SomethingElse target) {};
}
Thank you for the example, just to be clear about the second question:
As far as overriding goes, I've been able to change the type of the parameter, but if I try to have no parameters at all, I get error: CS0535, 'the class I'm trying to create' does not implement interface member 'IState.Update(DummyClass)'.
If I try to leave the parameters empty, then try to supply a type later on, I get the same error.
So I'm just trying to see if I can make it so I don't need any type at all if I don't want one.
Hopefully that clarifies what I'm asking a little bit.
Remember that hiding members is a big no-no in OOP land. The whole point of an interface is that when you use it you are comitted to implementing everything in it, not just part of it.
If you're in a situation where you only want to use part of an interface, consider separating the interface into smaller parts.
It's also possible there's a problem with your class hierarchies, but we can't really tell without seeing more code.
Point taken, setting things up a different way may indeed be the best way to go about it.
->It's also possible there's a problem with your class hierarchies, but we can't really tell without seeing more code.
Just for some more clarification, below I posted the Interface, as well as a Class that tries to implement Update() with no parameters so that you could see if there was anything else wrong with my scripts.
public interface IState {
//test interface used in a FFS$$anonymous$$.
void Update (DummyClass target);
}
public class Rest : IState {
public virtual void Update ()
{
ReturnA$$anonymous$$essage();
}
public void ReturnA$$anonymous$$essage ()
{
Debug.Log ("this came from the Rest Class");
}
}
Trying to compile like this gives that CS0535 error.
I don't know a whole lot about state machines (I think that's what you're trying to implement) so I can't really comment on your architecture specifically, but try to think about interfaces and inheritance in these terms:
If you are trying to make class Rest implement interface IState, but you don't want to implement all of IState, then Rest is not an IState, and you should rethink your architecture.
I see, thanks again for the help, its always appreciated.
Take a look to generic methods. Link to MSDN. It has your method accepting any kind of class.
For the no parameters part of your question you could make it null by default:
public interface IState {
//test interface used in a FFSM.
void Update (DummyClass target = null);
}
That will be OK calling it as "Update()" so in that case the parameter target would be null.
Thank you for the link, I will make sure to look at it.
Unfortunately, when I try your idea for a null parameter, I get error : CS0241, Default parameter specifiers are not permitted.
Any ideas on what I messed up?
Try this?
public interface IState {
DummyClass target = null;
void Update(target);
}
@TheDDestroyer12: Thank you for the idea, but when I try your suggestion as written I get: Error CS1001: Identifier expected (CS1001) on the line: void Update(target);
If I then add an identifier, I get: Error CS0525: Interfaces cannot contain fields (CS0525) on the line: DummyClass target = null;
Any ideas for that?
i'd just like to throw this in to see if it helps:
public interface IState {
//test interface used in a FFSM.
void Update (DummyClass target);
}
public class State : MonoBehaviour, IState
{
void Update() {
// If you want to call Update(DummyClass)
Update(default(DummyClass));
}
void Update(DummyClass dummy)
{
// do something with DummyClass
}
}
Note the use of default(DummyClass) assigning null to a Complex Type is invalid so use default instead which just so happens to return null in this case.
Uhm, maybe you read my answer on that other question, but i was talking about generic type parameters. In your case the parameter is a reference type. null can be assigned to any reference type. So while your use of "default" is possible, it's not necessary here and very unusual and just confuses.
Also this whole question (including most answers) is kinda, well, way off... The people who posted anything here should read about interfaces and what they are actually good for. Interfaces or base-classes are there to implement a common interface which is shared by all it's implementing / deriving classes. When you implement tons of seperate methods you don't need an interface. Interfaces provides a level of abstraction which is important to generalize the access to a concept. By implementing different methods you do the exact opposite.
The point of a FS$$anonymous$$ is to generalize the concept of a state machine. So the state machine itself doesn't know which state (which exact class) is the current state, all it knows is that it has an Update method which it should call. The FS$$anonymous$$ itself doesn't care about which state is active, it just calls the same method with the same parameters on the stored reference. It's able to do so because each state-class is required to implement the IState interface which describes that one method the FS$$anonymous$$ is calling.
I read this question already 2 days ago and wasn't sure what the OP actually wanted. Each time i got back here the whole thread has become more confusing. I just found some time to add my two cents :)
@Bunny83 I was merely illustrating how you could implement the said interface in a monobehaviour your comment seems to aim at the question itself rather than my answer.
Been coding a quite a bit with generics last few days so yes my default maybe misplaced but works as intended.
