Generics Problems
-
You missed that these are data entites that are both passed to the same form. The code in the forms is identical, except where the data is concerned. There's no good reason to have 2 forms.
If it's not broken, fix it until it is
-
I'm refactoring a WinForms project. I have 2 forms that do the same thing, except the data entities passed in are slightly different, so the guy who wrote them decided to duplicate the forms instead of making one form that works for both. So I'm refactoring them. Assume I have these 2 entites:
public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}In the CTOR of the form I have:
public partial class Form1 : Form
{
T entity;public Form1() { InitializeComponent(); entity = (T)Activator.CreateInstance(typeof(T)); }}
The problem is I now need to set properties on the object passed in. In most cases the 2 objects have the same name properties, but ther are differences. What is the right way to work with this object? Seems like I have no choice but to cast. Thanks
If it's not broken, fix it until it is
The best way to do this is to create an interface that encapsulates the common properties of your entities:
public interface IEntity
{
string SomeProperty { get; set; }
}public interface IAnotherInterface
{
string Name { get; set; }
}Each entity can inherit multiple interfaces, depending on how you want it set up:
public class Entity1 : IEntity, IAnotherInterface
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}If every entity has a certain interface, then you can require it in the Form definition:
public partial class Form1 : Form
where T : IEntityFinally, cast to the interfaces to set properties. If only some entities implement a given interface, check first.
void SetSomeProperties()
{
(entity as IEntity).SomeProperty = "foo";
if (entity is IAnotherInterface)
{
(entity as IAnotherInterface).Name = "bar";
}
} -
jschell wrote:
Obviously a good decision by that person because they are in fact different.
The fact that there seem to be common components between them is NOT sufficient reason to assume that they are the same. As an example the fact that Word and Visual Studio both allow me to type text doesn't mean that those two code bases should be merged.This is an entirely stupid argument. You're saying it's ok to have 2 entirely duplicate forms and their code becuase the data they work with is different.
jschell wrote:
The right way is to re-assess the decision to combine them in the first place. Nothing you have posted here suggests that they should be combined. And in fact what has been posted would suggest that they should NOT be combined.
Again, same form, same code, different data - There is NO good reason to have 2 identical forms.
If it's not broken, fix it until it is
Kevin Marois wrote:
This is an entirely stupid argument.
Nope. I have seen countless attempts by people to combine code based on nothing more than what they perceive as code duplication. That happens a lot with inheritance. It focuses on the duplication instead of focusing on the need.
Kevin Marois wrote:
You're saying it's ok to have 2 entirely duplicate forms and their code becuase the data they work with is different
What I said was that from what you posted here that is the case.
Kevin Marois wrote:
There is NO good reason to have 2 identical forms.
Actually there can be a very good reason. Because they represent two different conceptual entities. Because they are different it can mean that in the future they might go in different directions. Again code duplication is not the sole criteria that one uses to make this decision. And I gave you a specific example which would demonstrate why one wouldn't do that. Without more information all I can suppose is that what you really need, if indeed there is a real need at all, is a helper class. It contains the duplicated code. The current implementations would use that. That however still supposes that there is a real need to combine this code.
-
I'm refactoring a WinForms project. I have 2 forms that do the same thing, except the data entities passed in are slightly different, so the guy who wrote them decided to duplicate the forms instead of making one form that works for both. So I'm refactoring them. Assume I have these 2 entites:
public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}In the CTOR of the form I have:
public partial class Form1 : Form
{
T entity;public Form1() { InitializeComponent(); entity = (T)Activator.CreateInstance(typeof(T)); }}
The problem is I now need to set properties on the object passed in. In most cases the 2 objects have the same name properties, but ther are differences. What is the right way to work with this object? Seems like I have no choice but to cast. Thanks
If it's not broken, fix it until it is
Create an abstract Form class that contains all the "shared" code; then create 2 Forms that contain only the code / properties that are unique and inherit (are subclassed from) the abstract Form. 3 Forms, but simpler and cleaner than generics, reflection, (probably less code), etc. (IMO)