Develop Reference

Virtual method getting called instead of the override

I have four classes, Event and Action which are both base classes, and then I have two child classes Create : Event and MoveTo : Action.
Event contains a list of Action instances, and when Trigger() is called in the child Create it calls Event.Trigger(), which loops over the list of actions, and calls Action.Run() on each action which calls Called().
The Issue I am having is the virtual method is getting called and not the override method inside of MoveTo.
[Serializable]
public abstract class Event : MonoBehaviour {
[SerializeField] public List<Action> actions = new List<Action>();
protected void Trigger() {
foreach (Action action in actions) {
action.Run();
}
}
}
Event
public class Create : Event {
void Start() {
Trigger();
}
}
Action
[Serializable]
public class Action {
public virtual void Called() {
Debug.Log("Virtual");
}
public void Run() {
Called();
}
}
MoveTo
public class MoveTo : Action {
public override void Called() {
Debug.Log("Called");
}
}
I am adding the MoveTo action to the event list from the Unity Editor onto a prefab. I am not sure how unity handles these at runtime, does in initialize them or do I? That I am not sure about. That is what might be causing my issue...
private Event GetCurrentEvent(){}
void AddActionCallback(Type actionType) {
// actionType is MoveTo
var prefab = GetCurrentPrefabItem().Value;
var evt = GetCurrentEvent();
evt.actions.Add((Action)Activator.CreateInstance(actionType));
Undo.RecordObject(prefab.gameObject, "Added actions");
PrefabUtility.RecordPrefabInstancePropertyModifications(prefab.gameObject);
}
Here is what it looks like before I run the game. It shows MoveTo, the button in the red column shows the action using action.GetType().Name. This is the name before I run the game:
After I run the game the button now looks like this:
When running:
evt.actions.Add((Action)Activator.CreateInstance(actionType));
The editor displays Type mismatch even when the output of actionType and Activator.CreateInstance(actionType) is MoveTo:

Unity does not support built-in polymorphic serialization.
When you save the prefab, it serializes the List as a list of pure Actions, and erases any information that only the child class MoveTo has.
From the Unity docs on serialization:
No support for polymorphism
If you have a public Animal[] animals and
you put in an instance of aDog, a Cat and a Giraffe, after
serialization, you have three instances of Animal.
One way to deal with this limitation is to realize that it only
applies to custom classes, which get serialized inline. References to
other UnityEngine.Objects get serialized as actual references, and for
those, polymorphism does actually work. You would make a
ScriptableObject derived class or another MonoBehaviour derived class,
and reference that. The downside of this is that you need to store
that Monobehaviour or scriptable object somewhere, and that you cannot
serialize it inline efficiently.
The reason for these limitations is that one of the core foundations
of the serialization system is that the layout of the datastream for
an object is known ahead of time; it depends on the types of the
fields of the class, rather than what happens to be stored inside the
fields.
This is why its class shows up as an Action.
However, it can't serialize as an Action because:
How to ensure a custom class can be serialized
Ensure it:
Has the Serializable attribute
Is not abstract
Is not static
Is not generic, though it may inherit from a generic class
Action is an abstract class, so it won't even serialize partially properly. I assume this is the root cause of the Type Mismatch problem, as Unity is struggling to deserialize something that is unsupported.
In short, if you want to serialize data in MoveTo, you'll need to have a [SerializeField] List<MoveTo> in order to not lose the information, or you can have Action inherit from ScriptableObject, which brings its own problems.

Creating an abstract generic method

I have a C# class with a method such as below:
public class MyType
{
public MyType Clone()
{
var clone = (MyType)MemberwiseClone();
// Do some other stuff here with the clone's properties
return clone;
}
}
I have a bunch of other classes where I want to implement the Clone method so I was thinking I could create an abstract base class where I could define the Clone method generically so I don't have to put a concrete implementation in each class.
I would think this is possible but I haven't worked too much with generics and my attempts to do this in the past (months ago, so discarded my code out of frustration) haven't been successful.
Is this possible? If so, how could it be done?

Create an abstract generic base and then implement the concrete type on the derived ones:
public abstract class ClonableBase<T>
{
public T Clone()
{
return (T)this.MemberwiseClone();
}
}
public class RealClass : ClonableBase<RealClass> { }

The usefulness of this approach depends significantly on what it is that you're cloning.
Here's a method that I use. The cloning method is a bit crude. It's specifically for objects that are meant to be serialized as JSON.
That's why the generic constraint (TEntity : BaseEntity) is there. I don't want just anything passed into this method, only something that I know is serializable.
I also avoided using the generic argument for JsonConvert.DeserializeObject because while I want to cast the result as a specific type, I don't want to pass in an inherited type and get back an instance of a base type.
public static TEntity CloneEntity<TEntity>(this BaseEntity input) where TEntity
: BaseEntity
{
if (input == null) return null;
var serialized = JsonConvert.SerializeObject(input);
return (TEntity)JsonConvert.DeserializeObject(serialized, input.GetType());
}
Although it's already been accepted, I don't recommend adding this to a base class unless absolutely necessary. Before long you might find that you need to clone something that already inherits from a different base class.
This requires the Newtonsoft.JSON package.
As mentioned in a comment, this will do a deep clone. As I stated at the top, this method applies only if serialization/deserialization cloning is appropriate to the types you need to clone. If there were a universally applicable way to clone objects that applied in every case then object would probably have a public Clone method.
If we're cloning classes it's likely because they contain data, and where that's the case deep cloning is likely preferable. For example, suppose we have a Customer class, and one if its properties exposes an Address object. MemberwiseClone will clone the value types, but will result in two Customer objects that share a reference to the same Address. If we're cloning it's usually because we're trying to create entirely distinct objects. If we think we've cloned something but beneath the surface the original and clone share object references then there's a good chance we'll have bugs.

Built on #Gusman's solution I add the possibility to do some initialization
public abstract class ClonableBase<T>
{
public T Clone()
{
T clone = (T)MemberwiseClone();
Initialize(clone)
return clone;
}
protected virtual void Initialize(T clone)
{
}
}
If the initialization is mandatory, you can also make Initialize abstract instead.
public class RealClass : ClonableBase<RealClass> {
protected override void Initialize(T clone)
{
// Do some other stuff here with the clone's properties
}
}

Can't create dummy C# sensor class without getting no constructors defined error?

I have a C# Windows Phone 8 app that for phones that have it, uses the Compass sensor for a particular feature. I want to modify the class so that it can work on phones that don't have a compass sensor. I don't want to have to wrap every call to the Compass object in if (_compass != null) statements. I thought I could create a dummy Compass class with stubs for the Compass methods and properties, and create an instance of it instead of Compass if the phone doesn't have a compass, but I'm running into a problem with the abstract base class for the Compass class called SensorBase. No matter what I do, I get the compile time error:
Error 1 The type 'Microsoft.Devices.Sensors.SensorBase<TSensorReading>' has no constructors defined
The Compass class I'm trying to emulate can inherit from SensorBase without getting this error. I grabbed the exact declaration line for the Compass class, from the Sensors metadata file, and plugged it into my dummy class after changing the class name to CompassDummy, and I still get the error.
My guess is that the Compass class can inherit from SensorBase while my dummy class can't because it is in the same Assembly as SensorBase. Perhaps the constructor for SensorBase is marked internal or there is some other similar "friend" like relationship involved.
My question is, is there anything I can do in this situation to inherit from SensorBase without getting this error? If not, is there another solution involving dependency injection (IOC) that would help achieve my goal of instantiating a dummy class when the phone doesn't have a compass?
Here is my code for the CompassDummy class that is getting the error:
public sealed class CompassDummy : SensorBase<CompassReading>
{
public CompassDummy()
{
}
} // public class CompassDummy

My guess is that the Compass class can inherit from SensorBase while my dummy class can't because it is in the same Assembly as SensorBase. Perhaps the constructor for SensorBase is marked internal
Correct. You're not supposed to derive from SensorBase<T> yourself: it's just the base class for Accelerometer, Compass, Gyroscope, and Motion.
Are you planning to just use this dummy Sensor class within your own code, and not pass it anywhere? If so, use composition rather than inheritance here:
public interface ICompass
{
void Start();
// Whatever other methods you need
}
public class RealCompass : ICompass
{
private readonly Compass compass;
public RealCompass(Compass compass)
{
this.compass = compass;
}
public void Start()
{
this.compass.Start();
}
}
public class StubCompass : ICompass
{
public void Start()
{
// Do nothing...
}
}
Then, in your code, use your ICompass interface.

Using an interface to allow substitution of the concrete compass type, as suggested by canton7, is a good solution to this problem. Another solution to consider, depending on your needs, is the proxy pattern.
Basically, you'd create a CompassProxy class that you'd use throughout your code. This class would have similar or identical methods/properties to the framework Compass class, and each instance of it would contain a corresponding instance of either Compass or CompassDummy, depending on the phone's hardware.
Calls to the proxy class would be forwarded to the contained "back-end" compass class, which would do the real work and any result would then be passed back through to the caller.
Just as an illustration, here is some prototype code for a CompassProxy class:
class CompassProxy {
private readonly Compass _realCompass = null;
private readonly CompassDummy _dummyCompass = null;
private readonly bool _hasCompass = false;
public CompassProxy() {
// the creation logic could be moved out of this class, if need be
if ( HasRealCompassHardware() ) {
_realCompass = Compass.GetDefault(); // ...or whatever is the proper way to obtain an instance
_hasCompass = true;
} else {
_dummyCompass = new CompassDummy();
}
}
public CompassReading GetCurrentReading() {
return _hasCompass ? _realCompass.GetCurrentReading() : _dummyCompass.GetCurrentReading();
}
}

How to design a class with different sub structures

I have a class "Weapon" which has different behavior depending on its classification. The behavior can be changed at runtime, and the behavior can be replaced with others. (For those who know, I am describing a weapon of Worms: Armageddon).
Normally I would create different sub classes of "Weapon" which implement the specific behavior, but since it can be changed at runtime, I can't use such a "static typification".
I thought of a class weapon like the following (C#).
public class Weapon
{
public AirstrikeSettings _airstrikeSettings;
public MineSettings _mineSettings;
public LauncherSettings _launcherSettings,
}
The *Settings classes contain the parameters which define the exact behavior.
At runtime, it must be checked which of the 3 setting instances is not null, to find out what classification of weapon this is. If the classification is changed, for example from Mine to Airstrike, MineSettings are set to null and AirstrikeSettings are initialized.
Is that a correct way to design this case or do I have extreme design problems?
PS: If you are interested, this is the structure I want to reflect in my class: http://worms2d.info/Project_X/Weapon_file_block

As you already said, an inheritance based approach on the level of the Weapon will not allow you to change the behavior at runtime.
I'd suggest to have a look at the Strategy design pattern. It allows you to change the behavior of a class at runtime and you can avoid having lots of if-statements in the class itself.
So in your sample the Weapon class would be the context and the settings the Strategy. Instead of having three separate members for each type of settings, you'd have only one member for the current settings. If you make sure that this is always set, you don't have to check against null and you always call the current setting if you want to execute setting-specific behavior. In order for this to work, the settings need to be based upon a common structure.
In order to be able to set the behavior from the outside, you create a property for the current setting that is accessible from the outside of the class and thus allows a caller to change the setting at runtime.
So your sample would look similar to this:
// base strategy, can also be an abstract class if you want to share
logic between the settings
public interface IWeaponSettings
{
// Definition of common structure for the behaviors
void BehaveInSpecialWay();
// ...
}
public class AirstrikeSettings: IWeaponSettings
{
// Implementation for Airstrike
public void BehaveInSpecialWay()
{
// Airstrike
}
}
public class MineSettings : IWeaponSettings
{
// Implementation for Mining
public void BehaveInSpecialWay()
{
// Mining
}
}
// ...
public class Weapon
{
// Constructor that takes the initial settings as an input
public Weapon(IWeaponSettings settings)
{
Settings = settings
}
// Public property that can be used to change behavior.
// You might want to check against null in the setter
public IWeaponSettings Settings { get; set; }
public void DoSomething()
{
Settings.BehaveInSpecialWay();
}
}
Please note that if some settings do not support some behaviors, they still need to implement them, but simply do nothing or return a default value.

I suggest you create an abstract Weapon class, and three derived classes: AirstrikeWeapon, MineWeapon and LauncherWeapon. Each of these subclasses can have its own settings. Then, add an Attack method to the base class, and implement it using whatever logic you need in each derived class. Then, at runtime, each worm has a Weapon member which can be set to an instance of the weapon it's currently using.
This is called polymorphism, by the way.

Speaking simply, if I have to check null for knowing the type of a class at runtime, then what on earth the Inheritance is doing.
In your case, you can define an abstract class Settings which'll be the parent class of those 3 classes. Then class Weapon will only have the reference of class Settings. Please see the following code:
public abstract class Settings
{
}
public class AirstrikeSettings : Settings
{
}
public class MineSettings : Settings
{
}
public class LauncherSettings : Settings
{
}
public class Weapon
{
public Settings Settings { get; set; } // as this member is public, it can be declared as property
}

Any real example of using interface related to multiple inheritance

I m trying to understand Interfaces so that I can implement them in my programs but I m not able to imagine how should i use them.
Also give me some eg of using them with multiple inheritance in C#

A good example for an interface is a repository pattern. Your interface will define methods like Get, GetAll, Update, Delete, etc. No implementation, just function signatures.
Then, you can write a 'concrete' implementation of that class to work with, say, MySQL. Your UI should only refer to the interface, though.
Later, if you decide to change to Microsoft SQL, you write another concrete implementation, but your UI code doesn't have to change (much).
Multiple inheritance doesn't exist in C#, in the sense that you can only inherit from one 'concrete' class; though you can inherit (or 'implement') as many interfaces as you want.

I am writing a video game. In this video game I apply different forces to objects in the game. Thrust forces, impact forces, gravitational forces. While they are calculated differently, they all have the same basic elements. I need to call an update function that will evaluate the force and add the force to the object it's attached to.
So, what I've done is create an IForce interface that has an update function for its signature. All of my forces implement this interface:
public interface IForce
{
void Update(Particle particle, GameTime gameTime);
}
Here is a sample implementation.
public class Spring : IForce
{
private Particle ThisParticle;
private Particle ThatParticle;
private float K;
public Spring(Particle thisParticle, Particle thatParticle, float k)
{
ThisParticle = thisParticle;
ThatParticle = thatParticle;
}
public void Update(Particle particle, GameTime gameTime)
{
float X = Vector3.Length(ThisParticle - ThatParticle);
ThisParticle.Forces.Add(K * X);
}
}
The update function has a simplified spring force update to make it easier to understand.
This helps in a few ways.
I can completely change the way a force is calculated without effecting other parts of my code. I do this all the time. Along the same lines, it is rediculously easy for me to add new forces. As long as it implements the IForce interface I know it will mesh well with my existing code.
Another way it helps is with handling a large number of forces. I have a force registry that has a List of IForce. Since all forces implement that interface and have an Update function it's very easy to update all the forces in my game. When I create the force I add it to the list. Then, I loop through the list and call each elements update function without worrying about what type of force it is and all my forces update.
I use interfaces every day in a lot of different situations. They are fantastic!

Note :Interface is used to restrict and access the methods or events etc from differents classes at any cost, It means we can defined many more methods inside any class but when we are calling methods through Interface means we want only other than restricted methods. In the program below User1 can use Read & Write both but User2 can Write and Execute. See this Program below.........
namespace ExplConsole
{
class Program
{
static void Main ()
{
System.Console.WriteLine("Permission for User1");
User1 usr1 = new Test(); // Create instance.
usr1.Read(); // Call method on interface.
usr1.Write();
System.Console.WriteLine("Permission for User2");
User2 usr2 = new Test();
usr2.Write();
usr2.Execute();
System.Console.ReadKey();
}
}
interface User1
{
void Read();
void Write();
}
interface User2
{
void Write();
void Execute();
}
class Test : NewTest,User1, User2
{
public void Read()
{
Console.WriteLine("Read");
}
public void Write()
{
Console.WriteLine("Write");
}
}
class NewTest
{
public void Execute()
{
Console.WriteLine("Execute");
}
}
}
Output:
Permission for User1
Read
Write
Permission for User2
Write
Execute

Interfaces simply define a contract of the public elements (e.g. properties, methods, events) for your object, not behavior.
interface IDog
{
void WagTail(); //notice no implementation
ISound Speak(); //notice no implementation
}
class Spaniel : IDog
{
public void WagTail()
{
Console.WriteLine("Shook my long, hairy tail");
}
public ISound Speak()
{
return new BarkSound("yip");
}
}
class Terrier : IDog
{
public void WagTail()
{
Console.WriteLine("Shook my short tail");
}
public ISound Speak()
{
return new BarkSound("woof");
}
}
UPDATE
In "real examples" I use interfaces with:
- Unit Testing
- GENERICS (e.g. Repository, Gateway, Settings)
interface Repository<T>{
T Find(Predicate<T>);
List<T> ListAll();
}
interface Gateway<T>{
T GetFrom(IQuery query);
void AddToDatabase(IEntity entityItem);
}
interface Settings<T>{
string Name { get; set; }
T Value { get; set; }
T Default { get; }
}

Here is one (in Java, but this is not important since they're similiar):
In my project I've created simple interface:
public interface Identifiable<T> {
public T getId();
}
Which is simple replacement to some sorts of annotations. The next step: I've made all entity classes implement this interface.
The third step is to write some syntax-sugar-like methods:
public <T> List<T> ids(List<? extends Identifiable<T> entities) { ... }
This was just an example.
The more complex example is something like validation rules: you have some validation engine (probably written by you) and a simple interface for rule:
public interface ValidationRule {
public boolean isValid(...);
}
So, this engine requires the rules to be implemented by you. And of course there will be multiple inheritance since you'll certainly wish more then a single rule.

Multiple inheritance is about having a class be usable in multiple situations: [pseudo code]
interface Shape {
// shape methods like draw, move, getboundingrect, whatever.
}
interface Serializable {
// methods like read and write
}
class Circle : public Shape, public Serializable {
// TODO: implement Shape methods
// TODO: implement Serializable methods
}
// somewhere later
{
Circle circle;
// ...
deserializer.deserialize(circle);
// ...
graphicsurface.draw(circle);
// ...
serializer.serialize(circle);
}
The idea is that your Circle class implements two different interfaces that are used in very different situations.

Sometimes being too abstract just gets in the way and referring to implementation details actually clarifies things. Therefore, I'll provide the close to the metal explanation of interfaces that made me finally grok them.
An interface is just a way of declaring that a class implements some virtual functions and how these virtual functions should be laid out in the class's vtable. When you declare an interface, you're essentially giving a high-level description of a virtual function table to the compiler. When you implement an interface, you're telling the compiler that you want to include the vtable referred to by that interface in your class.
The purpose of interfaces is that you can implicitly cast a class that implements interface I to an instance of interface I:
interface I {
void doStuff();
}
class Foo : I {
void doStuff() {}
void useAnI(I i) {}
}
var foo = new Foo();
I i = foo; // i is now a reference to the vtable pointer for I in foo.
foo.useAnI(i); // Works. You've passed useAnI a Foo, which can be used as an I.

The simple answer, in my opinion, and being somewhat new to interfaces myself is that implementing an interface in a class essentially means: "This class MUST define the functions (and parameters) in the interface".
From that, follows that whenever a certain class implements the interface, you can be sure you are able to call those functions.
If multiple classes which are otherwise different implement the same interface, you can 'cast' them all to the interface and call all the interface functions on them, which might have different effects, since each class could have a different implementation of the functions.
For example, I've been creating a program which allows a user to generate 4 different kinds of maps. For that, I've created 4 different kind of generator classes. They all implement the 'IGenerator' interface though:
public interface IGenerator {
public void generateNow(int period);
}
Which tells them to define at least a "public generateNow(int period)" function.
Whatever generator I originally had, after I cast it to a "IGenerator" I can call "generateNow(4)" on it. I won't have to be sure what type of generator I returned, which essentially means, no more "variable instanceof Class1", "variable instanceof Class2" etc. in a gigantic if statement anymore.

Take a look at something you are familiar with - ie a List collection in C#. Lists define the IList interface, and generic lists define the IList interface. IList exposes functions such as Add, Remove, and the List implements these functions. There are also BindingLists which implement IList in a slightly different way.
I would also recommend Head First Design Patterns. The code examples are in Java but are easily translated into C#, plus they will introduce you to the real power of interfaces and design patterns.