I'm adding a replaying feature to my game. Having this feature, I can capture user's input to the game and feed them back to Unity later on for replaying the game. But the design of VRStandardAssets.Utils.VRInput class prevents me to mimic user inputs.
This class does not provide any public method to make it possible to trigger its events (e.g. OnClick or OnDoubleClick events) programmatically. So I decided to create a derived class from it and write my own public methods to trigger the events. This strategy failed because VRInput's methods are private meaning that I cannot invoke them from a derived class.
It is recommended for this type of classes to provide a protected virtual void On[eventName](subclassOfEventArgs e) method to provide a way for a derived class to handle the event using an override but this class does not have it (why so restrictive?). I guess it's a poor design from Unity. This poor design also makes it hard to write unit/integration tests.
Am I missing something here? Can I still do something to trick other classes to think they are dealing with VRInput class while replaying the game?
In fact you can trigger theses events (OnClick, OnDoubleClick or any other events) from another class and without using reflection using this clever hack (Inspired by this article):
C# is not really type safe so you can share the same memory location. First declare a class with two fields that share the same memory space:
[StructLayout(LayoutKind.Explicit)]
public class OverlapEvents
{
[FieldOffset(0)]
public VRInput Source;
[FieldOffset(0)]
public EventCapture Target;
}
Then you can declare a new class that will intercept and call the other event:
public class EventCapture
{
public event Action OnClick;
public void SimulateClick()
{
InvokeClicked();
}
// This method will call the event from VRInput!
private void InvokeClicked()
{
var handler = OnClick;
if (handler != null)
handler();
}
}
Then finally register it and call it:
public static void Main()
{
input = GetComponent<VRInput>();
// Overlap the event
var o = new OverlapEvents { Source = input };
// You can now call the event! (Note how Target should be null but is of type VRInput)
o.Target.SimulateClick();
}
Here is a simple dotNetFiddle that show it working (at least outside of unity)
It is recommended for this type of classes to provide a protected virtual void On[eventName](subclassOfEventArgs e) method to provide a way for a derived class to handle the event using an override but this class does not have it (why so restrictive?). I guess it's a poor design from Unity. This poor design also makes it hard to write unit/integration tests.
All code is good code. All code is also bad code. Depends on your evaluation criteria. Unity's developers probably didn't think about your use case. As another conflicting rule of thumb, software should also be as simple & rigid as possible, so anticipating subclassing without a known use case might be considered overengineering.
As for how you can work around this, see How do I raise an event via reflection in .NET/C#?
Related
I am trying to implement the following in C# so that I can force initialization of certain event delegates and variables in the parent classes, or I would use interface's instead. Obviously the below is not syntax correct.
the concrete class is Class1 & class 2.
the idea being here MyClass Is a button and it is an Image and it is something else.
Edit: " I understand that selectable and others are not objects but states. what I really want to do is to write the code that maintains the selectable state in the appropriate method because it will be the same for all of them. i.e. On click event( click location) check if i was I clicked based on my bounding box, update state to selected. I am in XNA, which is a c# polling environment, and I'm attempting to make the GUI as event driven as possible, if that makes any sense? "
public abstract class Class1
{
private int NumberNeededForMethod;
private void methodThatOccursWhenEventHappens(int NumberNeededForMethod)
{
// stuff using NumberNeededForMethod;
}
private Class1(int NumberNeededForMethod)
{
MethodDelegate += methodThatOccursWhenEventHappens(int
NumberNeededForMethod)
;
}
}
public abstract class Class2
{
private int NumberNeededForMethod2;
private void methodThatOccursWhenEventHappens2(int NumberNeededForMethod2)
{
// stuff using NumberNeededForMethod2;
}
Class2(int NumberNeededForMethod2)
{
MethodDelegate += methodThatOccursWhenEventHappens(int NumberNeededForMethod2);
}
}
public class ClassThatIsBothClass1andClass2: Class1, Class2
{
ClassThatIsBothClass1andClass2( int NumberNeededForMethod1, int NumberNeededForMethod2) : Class1(NumberNeededForMethod1),Class2(NumberNeededForMethod2)
{
}
}
You can use composition to create a class which wraps class1 and class2 and is the thing that responds to the event raised by your button.
First, of course, C# does not support multiple inheritance, so whatever polymorphism you implement will have to be accomplished using interfaces and composition.
Referring to this comment: Draggable, Selectable and Ownable are attributes of an object.
Image and Button, on the other hand, are objects.
A Button cannot be an Ownable.
But a Button can be Ownable, Draggable or Selectable. What I wonder is whether those attributes aren't just properties on a single IAshtonControl interface?
A Button can conceivably also be an Image. That makes perfect sense.
Because C# lacks multiple inheritance, you simply cannot create an AshtonButton class that derives from both Button and Image base classes.
One thing you can do is create an AshtonButton class that implements the IAshtonControl interface, and the implementation for that interface can delegate to a private instance of a worker class that does whatever work is common to all IAshtonControl instances.
Or you could have separate IOwnable, IDraggable and ISelectable interfaces if that is what is required.
Either way, it becomes possible to truthfully make the statement that AshtonButton is an IAshtonControl, is ownable, is draggable, is selectable. Those things might have different meanings (different behavior/visual effects) for different controls, or they might not, but you would hide those implementation details behind the interface(s) so that you could programmatically treat each object the same way regardless of its implementation.
It is important to separate the object from its attributes, because that affects the way you think about the problem. Draggable is not a thing, it is a characteristic of a thing.
But if your goal is to have a Button that is also an Image, some type of composition or delegation is the way to accomplish that. If you have a IAshtonImage interface, then you would implement that on both the AshtonImage class, and on the AshtonImageButton class. Then you have an internal instance (composition) of the AshtonImage class, within the AshtonImageButton class, and delegate calls to the IAshtonImage members through to the private (composed) AshtonImage instance, and so on.
I've got a couple of classes that form a too-complicated object graph. Here's a peek at a smaller scenario. Assume INotifyPropertyChanged is in place.
class A
{
public InternalType InterestingProperty { get; set; }
}
class B
{
public A Component { get; set; }
}
My helper class watches for these events and updates its properties when the properties of the objects change. It does this so some other class that's interested in about a dozen properties on as many objects are easily accessible. This is all packed in a framework that has several variants, so inheritance is in play.
I've finished the first scenario, and ended up with a concrete class like this:
class ScenarioOnePropertySpy
{
protected ScenarioOne PropertySpy(Foo thingToMonitor)
{
_thingToMonitor = thingToMonitor;
RegisterForEvents()
}
public B InterestingB { get; }
protected RegisterForEvents()
{
// * Register for _thingToMonitor propertyChanged if first time.
// * If B is different, unregister the old and register the new.
// * If B hasn't been set yet register for PropertyChanged on it.
// * If B.Component isn't the same as last time unregister the
// old and register the new.
}
protected Update()
{
// Some monitored object changed; refresh property values and
// update events in case some monitored object was replaced.
B = _thingToMonitor.B;
RegisterForEvents()
}
private Handle_PropertyChanged(...) { Update(); }
}
It's icky event registration, but moving that ugliness out of the class that wants to know about the properties is the purpose. Now I've moved on to scenario 2 that monitors different objects/properties and used my concrete class as a guide for an abstract one:
abstract class PropertySpy
{
protected PropertySpy(FooBase thingToMonitor)
{
_thingToMonitor = thingToMonitor;
RegisterForEvents()
}
protected abstract void RegisterForEvents()
// ...
}
Whoops. I've got a virtual method call in the constructor. In theory it's safe for all of my scenarios, but the R# warning keeps digging at me. I'm sure if I move forward one day it's going to cause a problem that'll take a while to figure out. That method's definitely going to need to work with properties on the derived types.
I could drop the method and force derived types to do the event management themselves. That'd defeat the purpose for the base class. And someone would forget to follow the contract and it'd turn into a support incident; I spend enough time writing documentation as it is. Another one I thought of was making RegisterForEvents() publich and requiring users to call it after construction. That "create then initialize" pattern stinks in .NET and people always forget. Currently I'm toying with the notion of another class that does the event registration that's injected via the constructor. Then derived classes can provide that class to achieve the same effect as a virtual method without the dangers. But the thing doing the registration would need practically the same property interface as PropertySpy; it seems tedious but I guess "ugly and works" is better than what I've got.
Anything I'm missing? I'll even take "it's a warning, not a rule" as an answer if the argument is convincing.
Your scenario seems complicated enough to consider a completely different approach to class instantiation. What about using a factory to construct property spies?
public class PropertySpyFactory<T> where T : PropertySpy, new()
{
public static T Create()
{
T result = new T();
// … whatever initialization needs to be done goes here …
result.RegisterForEvents();
return result;
}
}
ScenarioOnePropertySpy spy = PropertySpyFactory<ScenarioOnePropertySpy>.Create();
It's salvagable in the code, instance initialization can be extended easily, and once you turn to an IoC it will feel quite natural and not much refactoring will be needed.
UPDATE: One another option in case a) your spy hierarchy is flat enough and b) you don't need to use a common ancestor or you can substitute it with an interface:
public abstract class PropertySpy<T> where T : PropertySpy, new()
{
public static T Create()
{
T result = new T();
// … whatever initialization needs to be done goes here …
result.RegisterForEvents();
return result;
}
…
}
public class ScenarioOnePropertySpy : PropertySpy<ScenarioOnePropertySpy>
{
…
}
ScenarioOnePropertySpy spy = ScenarioOnePropertySpy.Create();
In other words, the factory method is located right within the common ancestor. The drawback of this approach is that it isn't that orthogonal (the factory isn't separated from the classes being constructed) and hence less extensible and flexible. However, in certain cases may be a valid option.
Last but not least, you can create a factory method in each class again. The advantage is you can keep constructors protected and hence force users to use factory methods instead of direct instantiation.
The key issue I believe is that by the time the virtual method is called, your subclass constructor and initializers have not executed yet. So, in your overridden method, your subclass may not have all the things you expect to be initialized initialized.
Is there a neat way to make several classes (which say derive from 1 interface), to each perform a same action? Think of http modules in ASP.NET which serve each request (Each the key word) - is there a way to perform some common action on derived types? Reflection may be one way, though I would be interested in a way at a base class level.
Thanks
Not with only an interface; you'd want an abstract class in the middle there:
abstract class Whatever : IFooable {
public virtual void Do () {
PreDo();
}
protected abstract void PreDo();
}
Then you call Do, and PreDo is automatically called first on all implementing types.
(Edit: Just to be clear, I made Do virtual so this means if you re-implement it you should call base.Do() as the first thing, just to ensure that it actually calls the parent method).
If your classes all derive from a common base class, you could put this logic in your common base class.
If I understand what you are asking correctly, then perhaps an event handler is the way to go?
If you need a bunch of objects to respond to some action, then events (also called "message passing") is the way to go.
Something like this?
class Foo
{
public event EventHandler PerformAction;
private void OnActionNeeded()
{
// A bunch of Bars need to do something important now.
if (PerformAction != null)
PerformAction.Invoke();
}
}
class Bar
{
public Bar(Foo fooToWatch)
{
fooToWatch.PerformAction += new EventHandler(Foo_PerformAction);
}
void Foo_PerformAction(object sender, EventArgs e)
{
// Do that voodoo that you do here.
}
}
May not be a complete answer but I am tempted to think in terms of AOP and attributes.
some references:
http://www.codeproject.com/KB/cs/ps-custom-attributes-1.aspx
http://www.postsharp.org/contributions/documentation/removing-duplicate-code-in-functions
The Template Method design pattern may apply to what you're asking.
http://www.dofactory.com/Patterns/PatternTemplate.aspx
The overall point of designing an interface is to provide a protocol between two components and hide the implementation part.
The interfaces serve as a communication medium.
And what you are asking seem to be specific to implementaion.
Which can be cleanly handled using utility classes(singleton with the method)
I do not suggest to have abstract class in ur current scenario.
The FrameworkElement object has DataContextChanged event. However, there is no OnDataContextChanged method that can be overridden.
Any ideas why?
If a method is virtual, then the user has the option to either augment the base functionalty by calling the base class method or replace the base class functionality by failing to call the base class method. For OnEvent() methods, if you don't call the base class method then the event will not be raised (that's the responsibility of the base class method.) If the base class performs some kind of state management inside of the OnEvent method, this means that the derived class can accidentally invalidate the state of the object if the user chooses to omit a call to the base class method. Documentation can specify "please always call the base class method", but there's no way to enforce it.
When I see an event that doesn't have a virtual OnEvent() method, I usually assume the method performs some kind of internal state management and the designers of the class want to guarantee their state management runs. This isn't the case in FrameworkElement, and it's not the only event that doesn't follow the pattern, so I'm curious what the reasoning is.
I dug around in Reflector to see if I could discover a reason. There is an OnDataContextChanged() method, but it's a dependency property change handler and doesn't follow the standard event pattern. This is probably the reason for not making it protected virtual. It's non-standard, so it would be confusing. It's static, so you wouldn't be able to override it anyway. Since it's called automatically by the dependency property framework and you are unable to override it, I believe we have the reason why it's private instead of static virtual.
You could use a different pattern to expose the normal event pattern:
class FrameworkElement
{
// difference: use DataContextPropertyChanged as the change callback
public static readonly DependencyProperty DataContextProperty = ...
protected virtual void OnDataContextChanged(...)
{
// raise the DataContextChanged event
}
private static void DataContextPropertyChanged(...)
{
((FrameworkElement)d).OnDataContextChanged(...);
}
}
My guess why they didn't do this? Usually you call OnEvent() to raise the event. The event is automatically raised when DataContext changes, and it doesn't make sense for you to raise it at any other time.
Good question.
I'm just guessing, but looking in Reflector I'd say it's just laziness, perhaps with a pinch of (unfounded?) performance concerns. FrameworkElement has a generic EventHandlersStore which is responsible for maintaining event information (delegates) for a whole bunch of events. The add and remove logic in the CLR events (such as DataContextChanged) simple call into the EventHandlersStore with the appropriate key.
There is a generic RaiseDependencyPropertyChanged method that is called to raise all different sorts of events. There is also a private OnDataContextChanged method that calls the RaiseDependencyPropertyChanged method. However, it is static and registered as part of the d-prop metadata.
So, in short, I see no technical reason not to include an overridable OnDataContextChanged method. Just looks like a short-cut in implementation to me.
Is this merely academic, or are you trying to achieve something here?
Silverlight Note:
At of Silverlight Beta 4 there IS no DataContextChanged event (well its not public at least).
The Microsoft Connect bug report has been marked as 'Fixed' but with no indication of what that actually means.
In the meantime you need a workaround such as this one from CodeProject - which is very simple and should be easy to switch out if Microsoft ever actually makes the event public.
Dependency properties usually don't have corresponding virtual methods for raising the event because it's expected that the change events will be managed by the dependecy property system itself.
What you can override however, to handle any dependency property changing is DependencyObject.OnPropertyChanged like so:
class MyClass : FrameworkElement {
protected override void OnPropertyChanged(DependencyPropertyChangedEventArgs e) {
base.OnPropertyChanged(e);
if (e.Property == FrameworkElement.DataContextProperty) {
// do something with e.NewValue/e.OldValue
}
}
}
I am using the mediator pattern to facilitate unit testing of GUI objects.
psudo code Example:
Class MyGuiClass
{
//... Declare and initialize mediator to be a MyMediator
private void On_SomeButtonPressed()
{
mediator.SomeButtonWasPressed();
}
}
Class MyMeditator
{
public void On_SomeButtonPressed()
{
//.. Do something now that the button was pressed
}
}
This is nice because I can now unit test what happens when SomeButton is pressed without having to create a Window.
My concern is that I have taken a method that was private and made it public for any one who makes a Mediator to call. Past times I have done this it did not bother me because I did not have many methods that I had to make public.
I am currently refactoring a very large class to use this pattern and I am wondering if there is someway I can control the visibility of who can make a MyMediator or which classes some of the methods are public for. (This may not be possible or even needed, but I thought I would ask.)
(I am using C# 3.0 with .NET 3.5 SP1)
I think it doesn't matter.. Who has an instance of the mediator, other than the gui? If someone does, is it going to call the method? If it does, does it matter? Will it be hard to notice, diagnose and fix the bug?
I think you can achieve what you are looking for with events though:
e.g.
/* in the gui class (view) */
public event EventHandler OnButtonClicked;
/* in the mediator */
public MyMediator(MyView view)
{
view.OnButtonClicked += HandleButtonClicked;
}
private void HandleButtonClicked(object sender, EventArgs e)
{
}
Not sure about c#, but in java you can declare something as package-level access (in java by omitting the access specifier). What I do is create a separate test hierarchy that parallels my package structure, so to test class com.a.b.c.MyClass, I'll have a test class com.a.b.c.MyClassTest, which can then legally access the package-access methods in MyClass.
I don't so much like the idea of making everything public not only because of access issues, but because it clutters up the interface - I'd rather the public interface of the class express what it does, not how it does it, which is often where I end up if I expose methods I'd prefer to be private.
The point is that you'd like the public interface of a class to show that class's public 'API', so in making private methods public you are making the class more confusing and less 'clean'?
A few things you can do:
1) think through what actually is the 'public face' of your mediator (or humble object) class and happily make those methods public. Even if they are only used within the assembly - not part of the assembly's public face - that's okay because notice that your mediator class itself is not declared public. So even its public methods are still internal to the assembly.
2) You can fudge the privates by using internal for private (and then set the assembly's InternalsVisibleTo attribute if your test classes are in a separate assembly).
3) Take the 'black box' approach to unit testing whereby in principle you never need to test the privates because they get tested via their use when called from the public methods.