2
\$\begingroup\$

I'm working C# on an exercise that is it very strange.

I have these three classes.

public abstract BaseClass<T> Where T : BaseClass<T>

public class Class1

public class Class2 : BaseClass<Class2>

On the exercise there is this strange declaration:

var dictionary = new Dictionary { [class1] = class1, [class2] = class2 };

I think that here, Dictionary is a shortcut for Dictionary<object, object> ; so I have added this class to the project:

public class Dictionary : Dictionary<object, object>

But I'm not sure if it is a good idea to inherit from Dictionary into a production environment (where I'm going to apply what I have learned).

So, I have decided to change the declaration on my custom dictionary class with this:

public class Dictionary
{
    Dictionary<object, object> dictionary = new Dictionary<object, object>();

    public object this[object index]
    {
        get
        {
            return dictionary[index];
        }

        set
        {
            dictionary[index] = value;
        }
    }

    public bool ContainsKey(object key)
    {
        return dictionary.ContainsKey(key);
    }
}

Which one is better?

By the way, I have to use ContainsKey in the exercise.

I can't modify the exercise. I have to create the classes that make it compiles and works (do whatever it does).

\$\endgroup\$
  • \$\begingroup\$ The generic parameters for Dictionary<TKey, TValue> are inferred here (they depend on the types of those class1 and class2 variables - for example, if those are Class1 objects then the compiler is smart enough to figure out that you need a Dictionary<Class1, Class1>). There should be no need for a custom Dictionary class. \$\endgroup\$ – Pieter Witvoet Jul 10 '17 at 9:09
  • \$\begingroup\$ @PieterWitvoet I can't modify the exercise. I have to create the classes that make it compiles and works (do whatever it does). And also, the keys could be from different types. \$\endgroup\$ – VansFannel Jul 10 '17 at 9:21
  • 3
    \$\begingroup\$ That doesn't look like a realistic scenario to me: you've been given code that doesn't compile, but you're not allowed to modify it? The most sane solution here would be to change new Dictionary to new Dictionary<object, object>, but you're not allowed to do that, so you have to create a Dictionary class. Composition is often better than inheritance, but inheriting from Dictionary<object, object> requires almost no code and quickly gets this hack-job done so it might be more economical in this particular case. Just be sure to add a comment about how it should be solved. \$\endgroup\$ – Pieter Witvoet Jul 10 '17 at 10:07
  • 1
    \$\begingroup\$ Another note: a Dictionary<object, object> is pretty much throwing away any type-safety/convenience that using a generic collection gives you, and it doesn't help in documenting purpose. Using a common base class or interface for values is a good idea. And for keys, you'll want to avoid using mutable types (modifying a key breaks lookup), so using object as TKey is a bad idea. Finally, using objects as keys for themselves is odd, as the given code does. Strange exercise indeed. My decision would be to talk to the person that gave me this assignment. ;) \$\endgroup\$ – Pieter Witvoet Jul 10 '17 at 11:23
  • 1
    \$\begingroup\$ @VansFannel take into consideration that the purpose of this exercise may be to see if you ask for clarification \$\endgroup\$ – RubberDuck Jul 10 '17 at 15:46

Your Answer

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

Browse other questions tagged or ask your own question.