i have the following methods:
public int CountProperty1
{
get
{
int count = 0;
foreach (var row in Data)
{
count = count + row.Property1;
}
return count ;
}
}
public int CountProperty2
{
get
{
int count = 0;
foreach (var row in Data)
{
count = count + row.Property2;
}
return count ;
}
}
what is the best way to avoid duplication here and share as much code as possible
How about using LINQ and the Sum extension method ?
public int CountProperty1
{
get { return Data.Sum(r => r.Property1); }
}
In case that is not an option, you can refactor out the logic into your own sum method:
public int CountProperty1
{
get
{
return CountProperty(r => r.Property1);
}
}
public int CountProperty2
{
get
{
return CountProperty(r => r.Property2);
}
}
private int CountProperty(Func<Row,int> countSelector)
{
int count = 0;
foreach (var row in Data)
{
count = count + countSelector(row);
}
return count ;
}
Note about the last example: I made up the "Row" type, as it was not evident from your example. Substitute with the proper type.
Probably not the answer you are looking for, but this is not necessarily duplication. There is a misunderstanding sometimes that if two different functions happen look the same, they should be refactored to remove the duplicate. In my humble opinion, THIS IS WRONG.
It is only dupliction if they are truly replication and identicial or near-identical concept. For it to be duplication (at least duplication that should be removed), it's not just that they happen to use the same code, but that the use the same code for the same reason.
It may just be because of the sample you posted, but it was simple enough. Despite the fact that the implemention of the two properties was identical, there must be some valid business reason that you have those two properties, otherwise the simplest answer is to remove the second property all together. However, if you really have two properties, and they just happen to look the same now, that doesn't mean they they won't diverge in functionility in the future (and that is OK).
The idea is to minimize complexity and maintenence cost. You can only do that if your code makes sense and models reality, but not if it introduces false comparisons by lumping together things that just happen to look similar.
http://mooneyblog.mmdbsolutions.com/index.php/2010/07/30/reusable-code-is-bad/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With