Generics Problems
-
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
OK What you need to do is create and interface:
public interface IEntity
{
string SomeProperty { get; set; }
string Caption { get; set; }
}Then use this interface on the classes:
public class Entity1 : IEntity
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2 : IEntity
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}Then use is in the generic:
public partial class Form1<T> : Form where T : IEntity, new()
{
T entity;public Form1() { InitializeComponent(); entity = new T(); }}
-
OK What you need to do is create and interface:
public interface IEntity
{
string SomeProperty { get; set; }
string Caption { get; set; }
}Then use this interface on the classes:
public class Entity1 : IEntity
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2 : IEntity
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}Then use is in the generic:
public partial class Form1<T> : Form where T : IEntity, new()
{
T entity;public Form1() { InitializeComponent(); entity = new T(); }}
Can't use an interface because most of this code is already in place. Have to work with what I have. However, I think this will do it:
public partial class Form1 : Form
{
T DataItem;
Type type = typeof(T);public Form1() { InitializeComponent(); var DistrictId = 10; DataItem = (T)Activator.CreateInstance(typeof(T), DistrictId); setProperty("Name", "The Name"); setProperty("LinkedToBilling", true); setProperty("BillingStartDate", new DateTime(2012, 01, 15)); } private void setProperty(string PropertyName, T Value) { var prop = DataItem.GetType().GetProperty(PropertyName); if (prop != null) { type.GetProperty(PropertyName).SetValue(DataItem, Value, null); } }}
This will allow me to attempt to set a property. Remember that in this case most of the properties exist on both objects. But this code allows me to not have multiple IF blocks. I think it's clean, and it solved the issue.
If it's not broken, fix it until it is
-
Can't use an interface because most of this code is already in place. Have to work with what I have. However, I think this will do it:
public partial class Form1 : Form
{
T DataItem;
Type type = typeof(T);public Form1() { InitializeComponent(); var DistrictId = 10; DataItem = (T)Activator.CreateInstance(typeof(T), DistrictId); setProperty("Name", "The Name"); setProperty("LinkedToBilling", true); setProperty("BillingStartDate", new DateTime(2012, 01, 15)); } private void setProperty(string PropertyName, T Value) { var prop = DataItem.GetType().GetProperty(PropertyName); if (prop != null) { type.GetProperty(PropertyName).SetValue(DataItem, Value, null); } }}
This will allow me to attempt to set a property. Remember that in this case most of the properties exist on both objects. But this code allows me to not have multiple IF blocks. I think it's clean, and it solved the issue.
If it's not broken, fix it until it is
Why bother with generics if you can't use them? You are better off doing things in a straight forward manner twice, than once in a non-obvious manner.
setProperty("Name", "The Name");
setProperty("LinkedToBilling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));May look like a nice, elegant solution, until you realize that
setProperty("Name", "The Name");
setProperty("LinkedToBiling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));doesn't give a compiler error.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Why bother with generics if you can't use them? You are better off doing things in a straight forward manner twice, than once in a non-obvious manner.
setProperty("Name", "The Name");
setProperty("LinkedToBilling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));May look like a nice, elegant solution, until you realize that
setProperty("Name", "The Name");
setProperty("LinkedToBiling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));doesn't give a compiler error.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Ennis Ray Lynch, Jr. wrote:
doesn't give a compiler error.
Exactly. If a property doesn't exist, then I don't want a compiler error.
If it's not broken, fix it until it is
-
Ennis Ray Lynch, Jr. wrote:
doesn't give a compiler error.
Exactly. If a property doesn't exist, then I don't want a compiler error.
If it's not broken, fix it until it is
I am going to have to go out on a limb here and say that yes you do. If you don't then you probably need to reconsider your approach. You are refactoring code here, refactoring implies, improving, not reducing lines of code, increasing complexity, or reducing maintainability. This fails the smell test. If you can't add improvement, don't refactor.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Can't use an interface because most of this code is already in place. Have to work with what I have. However, I think this will do it:
public partial class Form1 : Form
{
T DataItem;
Type type = typeof(T);public Form1() { InitializeComponent(); var DistrictId = 10; DataItem = (T)Activator.CreateInstance(typeof(T), DistrictId); setProperty("Name", "The Name"); setProperty("LinkedToBilling", true); setProperty("BillingStartDate", new DateTime(2012, 01, 15)); } private void setProperty(string PropertyName, T Value) { var prop = DataItem.GetType().GetProperty(PropertyName); if (prop != null) { type.GetProperty(PropertyName).SetValue(DataItem, Value, null); } }}
This will allow me to attempt to set a property. Remember that in this case most of the properties exist on both objects. But this code allows me to not have multiple IF blocks. I think it's clean, and it solved the issue.
If it's not broken, fix it until it is
You can also define something a dynamic, thus solve the problem. Also, you "should" go back and fix the code as just good coding practice. All you have to do is define the interface, and then find all classes that work with the form and add the interface. It will inprove preformace since eliminate need to use reflection.
-
I am going to have to go out on a limb here and say that yes you do. If you don't then you probably need to reconsider your approach. You are refactoring code here, refactoring implies, improving, not reducing lines of code, increasing complexity, or reducing maintainability. This fails the smell test. If you can't add improvement, don't refactor.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
It solves what I'm trying to accomplish. Lines of code, prettyiness, ect, are not the prime concern. I'm trying to make a form work for more than one entity. Added multiple block of duplpicate code is exactly what I DON'T want. Having said that, do you have an alternate solution?
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
If the classes aren't common enough then you can't. And I'd pass an instance into the Form's constructor if I could.
public interface IX { ... }
public class X0 : IX { ... }
public class X1 : IX { ... }public class MyForm
{
private IX x ;
public MyForm ( IX X ) { ... }
}IX x = new X0 ( ... ) ;
MyForm f = new MyForm ( x ) ; -
It solves what I'm trying to accomplish. Lines of code, prettyiness, ect, are not the prime concern. I'm trying to make a form work for more than one entity. Added multiple block of duplpicate code is exactly what I DON'T want. Having said that, do you have an alternate solution?
If it's not broken, fix it until it is
I wouldn't use it but you can use the wrapper pattern below. It isn't elegant, but is a way to handle what you want without changing the underlying objects using interfaces, which really is probably the best solution.
public class Wrapper{
private Object mObject;
public string Name{
get{
string result = null;
if(mObject is SomeTypeIRecognize){
result = ((SomeTypeIRecognize)mObject).Name;
}
return result;} } public Wrapper(object o){mObject = o;}}
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Why bother with generics if you can't use them? You are better off doing things in a straight forward manner twice, than once in a non-obvious manner.
setProperty("Name", "The Name");
setProperty("LinkedToBilling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));May look like a nice, elegant solution, until you realize that
setProperty("Name", "The Name");
setProperty("LinkedToBiling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));doesn't give a compiler error.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
I have to agree. There appears to be no reason to use generics.
-
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
-
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
Kevin Marois wrote:
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.
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.
Kevin Marois wrote:
What is the right way to work with this object?
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. Of course maybe there is some other factor that makes it obvious.
-
Kevin Marois wrote:
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.
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.
Kevin Marois wrote:
What is the right way to work with this object?
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. Of course maybe there is some other factor that makes it obvious.
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
-
I wouldn't use it but you can use the wrapper pattern below. It isn't elegant, but is a way to handle what you want without changing the underlying objects using interfaces, which really is probably the best solution.
public class Wrapper{
private Object mObject;
public string Name{
get{
string result = null;
if(mObject is SomeTypeIRecognize){
result = ((SomeTypeIRecognize)mObject).Name;
}
return result;} } public Wrapper(object o){mObject = o;}}
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
That is exaclty what I'm trying to avoid - lots of IF blocks all over the place. The generic & reflection code I posted will work fine.
If it's not broken, fix it until it is
-
Um, whaaa?
If it's not broken, fix it until it is
-
Um, whaaa?
If it's not broken, fix it until it is
public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}Looks like the same two classes to me. What did I miss?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}Looks like the same two classes to me. What did I miss?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
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
-
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.