1

I'm having an interface ProgressReporter which basically takes a list of input items (the working queue) through a method SetWorkPackages(IEnumerable<T> workPackages) and then has another method FinishedWorkPackage(T workPackage) to indicate that one package has been finished.

It will then handle this the correct way, i.e. display a new percentage number, update a progress bar on the UI, whatever is implemented.

Using generics, I have to call it like this:

var cpr = new ConsoleProgressReporter<WorkPackage>();
cpr.SetWorkPackages(...);
cpr.FinishedWorkPackage(...);

Actually, I have the feeling that the user does not really care about the type T, because he never gets results back through the API. Even internally in the current implementations, it does not matter what type T is.

Is it ok in such cases, to just allow object instead of using generics? Are there general guidelines when to use generics and when to use object?

2

If it makes no difference whatsoever what the element type is, then sure, you could ignore the fact that they're T objects. But if you're never going to perform any T-specific operations on them, why store the objects at all? You might be better off with just a counter recording how many they are.

The only situation where I can imaging holding things as Objects makes sense is if you want to call Object-defined methods but not T-defined methods in them, e.g. toString(). But frankly, there aren't all that many useful Object methods to begin with.

  • Actually one thing I'm currently doing is call .ToString() in the ConsoleProgressReporter. But that's more "using what is there", I would not need it desperately. The more important advantage I saw in saving the object (the hash would also be ok) was to double check internally, if FinishedWorkPackage() was called two times for the same object. – Aufziehvogel Jun 11 '15 at 7:28
  • 1
    @Aufziehvogel small side note - the hash is not normally completely unique – AlexFoxGill Jun 11 '15 at 11:19
  • @AlexFoxGill But equals() should be. I think enforcing uniqueness via equals (or equivalently, storing things in a Set) would be a valid reason to retain the items as Objects. – Kilian Foth Jun 11 '15 at 11:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.