I have a superclass with two subclasses. The two subclasses both have a method with checks whether a chapter has content. For subclass 1 this method is HasContent(int chapterID) and for subclass 2 this is HasContent(int chapterID, int institution). As you can see subclass 2 has an extra parameter. The purpose of both methods is the same.
I was thinking to put the method HasContent in the superclass. Do you think i need to do this? If so, how should i implement this? Or is it more wisely to put both methods in their own subclass?
EDIT:
The body of HasDocuments looks like this:
Subclass1:
Database DB = new Database();
int res = DB.ExecuteSpRetVal(chapterID, mInstitutionID);
if (res > 0)
return true;
else
return false;
Subclass2:
Database DB = new Database();
int res = DB.ExecuteSpRetVal(chapterID);
if (res > 0)
return true;
else
return false;
Edit: Updated according to the question update.
Since you are clearly having almost the same logic in both methods, I'd refactor it like this:
abstract class SuperClass
{
protected bool HasContentImpl(int chapterID, int institution)
{
Database db = new Database();
int result;
if (institution >= 0) // assuming negative numbers are out of range
result = db.ExecuteSpRetVal(chapterID, institution);
else
result = db.ExecuteSpRetVal(chapterID);
return result > 0;
}
}
class SubClass1 : SuperClass
{
public bool HasContent(int chapterID)
{
return base.HasContentImpl(chapterID, -1);
}
}
class SubClass2 : SuperClass
{
public bool HasContent(int chapterID, int institution)
{
return base.HasContentImpl(chapterID, institution);
}
}
Use method overloading by placing two identically named methods with different arguments into the superclass. When you call HasContent, it will use whichever one matches the number and types of arguments you have provided. Because it is in the superclass, you now won't have to make yet another copy of it if you decide later to make a new subclass that uses this method as well. See below for example code;
protected bool HasContent(int chapterID, int institution)
{
Database db = new Database();
int result;
result = db.ExecuteSpRetVal(chapterID, institution);
return result > 0;
}
protected bool HasContent(int chapterID)
{
Database db = new Database();
int result;
result = db.ExecuteSpRetVal(chapterID);
return result > 0;
}
You said:
The purpose of both methods is the same
so yes, it does sounds that you've got a common method that you can put in the superclass.
As HasContent() takes different augments I would not move it up to the base class, the fact that two methods are called the same, does not mean they do the same thing.
I don’t know your code base or what the system you are working on does, however given the little information I have, some thing about your design feels wronge. I have found in the past that often when I have this sort of design problem, it is due to a problem else where in how the data is model. Sorry not match help if you can’t change the rest of the system….
Related
Been bouncing back and forth between Swift and C# and I'm not sure if I'm forgetting certain things, or if C# just doesn't easily support what I'm after.
Consider this code which calculates the initial value for Foo:
// Note: This is a field on an object, not a local variable.
int Foo = CalculateInitialFoo();
static int CalculateInitialFoo() {
int x = 0;
// Perform calculations to get x
return x;
}
Is there any way to do something like this without the need to create the separate one-time-use function and instead use an instantly-executing lambda/block/whatever?
In Swift, it's simple. You use a closure (the curly-braces) that you instantly execute (open and closed parentheses), like this:
int Foo = {
int x = 0
// Perform calculations to get x
return x
}()
It's clear, concise and doesn't clutter up the object's interface with functions just to initialize fields.
Note: To be clear, I do NOT want a calculated property. I am trying to initialize a member field which requires multiple statements to do completely.
I wouldn't suggest doing this, but you could use an anonymous function to initialize
int _foo = new Func<int>(() =>
{
return 5;
})();
Is there a reason you would like to do it using lambdas rather than named functions, or as a calculated property?
I assume you want to avoid calculated properties because you want to either modify the value later, or the computation is expensive and you want to cache the value.
int? _fooBacking = null;
int Foo
{
get
{
if (!_fooBacking.HasValue)
{
_fooBacking = 5;
}
return _fooBacking.Value;
}
set
{
_fooBacking = value;
}
}
This will use what you evaluate in the conditional the first time it is gotten, while still allowing the value to be assigned.
If you remove the setter it will turn it into a cached calculation. Be careful when using this pattern, though. Side-effects in property getters will be frowned upon because they make the code difficult to follow.
To solve the problem in the general case you'd need to create and then execute an anonymous function, which you can technically do as an expression:
int Foo = new Func<int>(() =>
{
int x = 0;
// Perform calculations to get x
return x;
})();
You can clean this up a bit by writing a helper function:
public static T Perform<T>(Func<T> function)
{
return function();
}
Which lets you write:
int Foo = Perform(() =>
{
int x = 0;
// Perform calculations to get x
return x;
});
While this is better than the first, I think it's pretty hard to argue that either is better than just writing a function.
In the non-general case, many specific implementations can be altered to run on a single line rather than multiple lines. Such a solution may be possible in your case, but we couldn't possibly say without knowing what it is. There will be cases where this is possible but undesirable, and cases where this may actually be preferable. Which are which is of course subjective.
You could initialize your field in the constructor and declare CalculateInitialFoo as local function.
private int _foo;
public MyType()
{
_foo = CalculateInitialFoo();
int CalculateInitialFoo()
{
int x = 0;
// Perform calculations to get x
return x;
}
}
This won't change your code too much but you can at least limit the scope of the method to where it's only used.
I implemented CompareTo() like so:
public override int CompareTo(object obj)
{
//quick failsafe
MyClass other;
if (obj is MyClass)
{
other = obj as MyClass;
}
else
{
return 1;
}
//now we should have another comparable object.
/*
* 1: this is greater.
* 0: equals.
* -1: this is less.
*/
if (other.GetValue() < this.GetValue())
{
// this is bigger
return 1;
}
else if (other.GetValue() > this.GetValue())
{
//this is smaller
return -1;
}
else
{
return 0;
}
}
However, things get interesting when I want to chose the function GetValue(). I have a couple of them set up for that: namely Average(), Best(), CorrectedAverage(), Median(). I compare by an array of floats by the way. Thing is, I don't want to use a switch-case on an enum I defined in this class to tell what to order by. Is there a way that I decide which function to order by nice and clean?
Given that your class has a whole bunch of different ways of comparing it, it almost certainly shouldn't implement IComparable at all.
Instead, create IComparer<T> instances for each different way of comparing your object. Someone who wants to comparer instances of the type can then pick the comparer that uses the comparison that's most appropriate for their situation.
I'm currently working on a Solution to compare two elemts of the same object with eachother.
Code looks like this:
public double Compare(Data o)
{
double same = 0;
double different = -1;
foreach (var prop in o.GetType().GetProperties())
{
if (prop.GetValue(o) == prop.GetValue(this))
same++;
else
different++;
}
return (same / (different + same)) * 100;
}
Data is an example for an implementation of the IData Interface, created by my own. Since there are more types of different datastructures, there are identical implementations of the function in each and every object, that implements the particular interface.
Now, this kinda disturbes me because it seems to be stupid to have the exact same lines of code in different classes.
Is there any chance, that I can use one method for all of my different classes and still work with reflection?
I thought about the szenario quite a while and just couldn't figure out how to refere to the correct "this" reference. Only idea I got is, to write an helper class with two parameters for the function and call that helper method in the specific data call implementation.
Code would look like this:
class CompareHelper
{
public double Compare(Data o, Data callingObject)
{
double same = 0;
double different = -1;
foreach (var prop in o.GetType().GetProperties())
{
if (prop.GetValue(o) == prop.GetValue(callingObject))
same++;
else
different++;
}
return (same / (different + same)) * 100;
}
}
Any other recommendations?
Thanks in advance!
I don't know why I could figure it out by myself.
I'm now working with an abstract class, which implements the compare method (as stated above) and all the different types are specializations of the base class "Data".
Take the following:
var x = new Action(() => { Console.Write("") ; });
var y = new Action(() => { });
var a = x.GetHashCode();
var b = y.GetHashCode();
Console.WriteLine(a == b);
Console.WriteLine(x == y);
This will print:
True
False
Why is the hashcode the same?
It is kinda surprising, and will make using delegates in a Dictionary as slow as a List (aka O(n) for lookups).
Update:
The question is why. IOW who made such a (silly) decision?
A better hashcode implementation would have been:
return Method ^ Target == null ? 0 : Target.GetHashcode();
// where Method is IntPtr
Easy! Since here is the implementation of the GetHashCode (sitting on the base class Delegate):
public override int GetHashCode()
{
return base.GetType().GetHashCode();
}
(sitting on the base class MulticastDelegate which will call above):
public sealed override int GetHashCode()
{
if (this.IsUnmanagedFunctionPtr())
{
return ValueType.GetHashCodeOfPtr(base._methodPtr);
}
object[] objArray = this._invocationList as object[];
if (objArray == null)
{
return base.GetHashCode();
}
int num = 0;
for (int i = 0; i < ((int) this._invocationCount); i++)
{
num = (num * 0x21) + objArray[i].GetHashCode();
}
return num;
}
Using tools such as Reflector, we can see the code and it seems like the default implementation is as strange as we see above.
The type value here will be Action. Hence the result above is correct.
UPDATE
My first attempt of a better implementation:
public class DelegateEqualityComparer:IEqualityComparer<Delegate>
{
public bool Equals(Delegate del1,Delegate del2)
{
return (del1 != null) && del1.Equals(del2);
}
public int GetHashCode(Delegate obj)
{
if(obj==null)
return 0;
int result = obj.Method.GetHashCode() ^ obj.GetType().GetHashCode();
if(obj.Target != null)
result ^= RuntimeHelpers.GetHashCode(obj);
return result;
}
}
The quality of this should be good for single cast delegates, but not so much for multicast delegates (If I recall correctly Target/Method return the values of the last element delegate).
But I'm not really sure if it fulfills the contract in all corner cases.
Hmm it looks like quality requires referential equality of the targets.
This smells like some of the cases mentioned in this thread, maybe it will give you some pointers on this behaviour. else, you could log it there :-)
What's the strangest corner case you've seen in C# or .NET?
Rgds GJ
From MSDN :
The default implementation of
GetHashCode does not guarantee
uniqueness or consistency; therefore,
it must not be used as a unique object
identifier for hashing purposes.
Derived classes must override
GetHashCode with an implementation
that returns a unique hash code. For
best results, the hash code must be
based on the value of an instance
field or property, instead of a static
field or property.
So if you have not overwritten the GetHashCode method, it may return the same. I suspect this is because it generates it from the definition, not the instance.
I have a class that I have to call one or two methods a lot of times after each other. The methods currently return void. I was thinking, would it be better to have it return this, so that the methods could be nested? or is that considerd very very very bad? or if bad, would it be better if it returned a new object of the same type? Or what do you think? As an example I have created three versions of an adder class:
// Regular
class Adder
{
public Adder() { Number = 0; }
public int Number { get; private set; }
public void Add(int i) { Number += i; }
public void Remove(int i) { Number -= i; }
}
// Returning this
class Adder
{
public Adder() { Number = 0; }
public int Number { get; private set; }
public Adder Add(int i) { Number += i; return this; }
public Adder Remove(int i) { Number -= i; return this; }
}
// Returning new
class Adder
{
public Adder() : this(0) { }
private Adder(int i) { Number = i; }
public int Number { get; private set; }
public Adder Add(int i) { return new Adder(Number + i); }
public Adder Remove(int i) { return new Adder(Number - i); }
}
The first one can be used this way:
var a = new Adder();
a.Add(4);
a.Remove(1);
a.Add(7);
a.Remove(3);
The other two can be used this way:
var a = new Adder()
.Add(4)
.Remove(1)
.Add(7)
.Remove(3);
Where the only difference is that a in the first case is the new Adder() while in the latter it is the result of the last method.
The first I find that quickly become... annoying to write over and over again. So I would like to use one of the other versions.
The third works kind of like many other methods, like many String methods and IEnumerable extension methods. I guess that has its positive side in that you can do things like var a = new Adder(); var b = a.Add(5); and then have one that was 0 and one that was 5. But at the same time, isn't it a bit expensive to create new objects all the time? And when will the first object die? When the first method returns kind of? Or?
Anyways, I like the one that returns this and think I will use that, but I am very curious to know what others think about this case. And what is considered best practice.
The 'return this' style is sometimes called a fluent interface and is a common practice.
I like "fluent syntax" and would take the second one. After all, you could still use it as the first, for people who feel uncomfortable with fluent syntax.
another idea to make an interface like the adders one easier to use:
public Adder Add(params int[] i) { /* ... */ }
public Adder Remove(params int[] i) { /* ... */ }
Adder adder = new Adder()
.Add(1, 2, 3)
.Remove(3, 4);
I always try to make short and easy-to-read interfaces, but many people like to write the code as complicated as possible.
Chaining is a nice thing to have and is core in some frameworks (for instance Linq extensions and jQuery both use it heavily).
Whether you create a new object or return this depends on how you expect your initial object to behave:
var a = new Adder();
var b = a.Add(4)
.Remove(1)
.Add(7)
.Remove(3);
//now - should a==b ?
Chaining in jQuery will have changed your original object - it has returned this.
That's expected behaviour - do do otherwise would basically clone UI elements.
Chaining in Linq will have left your original collection unchanged. That too is expected behaviour - each chained function is a filter or transformation, and the original collection is often immutable.
Which pattern better suits what you're doing?
I think that for simple interfaces, the "fluent" interface is very useful, particularly because it is very simple to implement. The value of the fluent interface is that it eliminates a lot of the extraneous fluff that gets in the way of understanding. Developing such an interface can take a lot of time, especially when the interface starts to be involved. You should worry about how the usage of the interface "reads"; In my mind, the most compelling use for such an interface is how it communicates the intent of the programmer, not the amount of characters that it saves.
To answer your specific question, I like the "return this" style. My typical use of the fluent interface is to define a set of options. That is, I create an instance of the class and then use the fluent methods on the instance to define the desired behavior of the object. If I have a yes/no option (say for logging), I try not to have a "setLogging(bool state)" method but rather two methods "WithLogging" and "WithoutLogging". This is somewhat more work but the clarity of the final result is very useful.
Consider this: if you come back to this code in 5 years, is this going to make sense to you? If so, then I suppose you can go ahead.
For this specific example, though, it would seem that overloading the + and - operators would make things clearer and accomplish the same thing.
For your specific case, overloading the arithmetic operators would be probably the best solution.
Returning this (Fluent interface) is common practice to create expressions - unit testing and mocking frameworks use this a lot. Fluent Hibernate is another example.
Returning a new instance might be a good choice, too. It allows you to make your class immutable - in general a good thing and very handy in the case of multithreading. But think about the object creation overhead if immutability is of no use for you.
If you call it Adder, I'd go with returning this. However, it's kind of strange for an Adder class to contain an answer.
You might consider making it something like MyNumber and create an Add()-method.
Ideally (IMHO), that would not change the number that is stored inside your instance, but create a new instance with the new value, which you return:
class MyNumber
{
...
MyNumber Add( int i )
{
return new MyNumber( this.Value + i );
}
}
The main difference between the second and third solution is that by returning a new instance instead of this you are able to "catch" the object in a certain state and continue from that.
var a = new Adder()
.Add(4);
var b = a.Remove(1);
var c = a.Add(7)
.Remove(3);
In this case both b and c have the state captured in a as a starting point.
I came across this idiom while reading about a pattern for building test domain objects in Growing Object-Oriented Software, Guided by Tests by Steve Freeman; Nat Pryce.
On your question regarding the lifetime of your instances: I would exspect them to be elligible for garbage collection as soon as the invocation of Remove or Add are returning.