Breaking Change: Remove Unneeded Interfaces

We currently have many interfaces in Avalonia which mirror concrete classes, for example (list is not exhaustive):

• IAvaloniaObject -> AvaloniaObject
• IControl -> Control
• IInteractive -> Interactive
• ILayoutable -> Layoutable
• IPanel -> Panel
• IStyledElement -> StyledElement
• ITemplatedControl -> TemplatedControl
• IVisual -> Visual

These interfaces were added at the beginning of the project at a time where the prevailing fashion in unit testing was “create an interface for each concrete class in order to make it easier to mock”.

This turned out to be a mistake because:

• Using interfaces instead of concrete classes means that every method call is a virtual method call. This degrades performance in large applications and can be particularly noticeable when profiling on slower embedded and mobile hardware
• We still target netstandard2.0 which includes platforms such as .NET framework where default interface implementations are not supported, meaning that we can’t even add methods to these interfaces without breaking API compatibility
• Mocking is unnecessary in the unit tests anyway: it’s much better to use concrete classes
• Implementing these interfaces in user code isn’t supported by much of the code anyway

For 11.0 we should remove these interfaces to improve performance. This will be a large breaking change, but we feel it’s necessary, and the fix should be reasonably straightforward - remove a bunch of I characters.

[amwx]

I think just making it a virtual read-only property on StyledElement would be best solution. Overridable things also show up in intellisense so probably more intuitive this way. Would be to simple fix in existing code too: Type IStyleable.StyleKey => typeof(MyControl); --> public override Type StyleKey => typeof(MyControl)

[grokys]

BTW, why aren’t we using the WPF approach with DefaultStyleKeyProperty?

Historical reasons really: back in 2015 when I didn’t know anyone would ever use this project, I decided to implement it like that. Mostly because in WPF, I always forgot the step of setting a new default value for DefaultStyleKeyProperty and it annoyed me because 90% of the time “of course I want a new style for this new control I’m writing”.

However if we want to change it to match WPF/UWP etc then now would be the time to do it. Bear in mind though that reading the default value of a styled property is a lot slower than reading a virtual CLR property, and we’d be potentially reading the property a lot more than WPF does due to our CSS-like styling system.