I’m still new with C#, and I’m working on a project where we also use WPF, and the WPF DataGrid Toolkit (See at CodePlex), which hasn’t yet been released into the framework. Due to the nature of the project, it’s 100% sure we will be altering some controls of the assembly later. My co-workers have decided to redefine every control from the datagrid within a namespace of our project, and ihnerit the specific control of the assembly namespace. So instead of using: clr-namespace:Microsoft.Windows.Controls.Primitives;assembly=WPFToolkit clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit We’ll be using our own xxx.Controls and xxx.Controls.Primitives Namespaces. This way, it would be pretty easy to alter the ihnerited controls.
Somehow, I got a bad feeling about this solution, but I’m still inexperienced and cannot tell if such an approach is legitimate or not, or if there is another good solution to our requirements (altering the controls later without changing too much code in multiple files).
It would be nice if you express your opinion to this approach.
What kind of alterations are you talking about? It seems like a waste of time to pre-emptively derive from each of the classes before you know what you’ll actually need to change.
When you do need to change something, it shouldn’t be too hard to create the derived class at that point, and fix up any references – which may only be for some instances rather than all of them. Yes, it may mean check-ins involving quite a few files – but if you’re using a sensible source control system it will be an atomic change, and it will be obvious why it’s changing.
With your current approach, there’s no immediate ‘these are the controls we’ve had to change’ – if you do it in a ‘just-in-time’ manner, you’ll be able to tell just by looking at what derived controls you’ve actually had to create.