Dictionary<> and Inheritance

  • Thread starter Thread starter Brian P
  • Start date Start date
B

Brian P

I want to expose a property of Dictionary<string, MyAbstractClass>.

I tried to do it this way:

private Dictionary<string, MyChildClass> _dictionary;

public Dictionary<string, MyAbstractClass>
{
get { return _dictionary; } //error: no implicit conversion.
}



How can I have a privay dictionay that uses an inheritied class, but
expose that dictionary as the base type?


--Brian
 
No, and here is why.

Let's say that you could expose a dictionary of MyChildClass objects as
a dictionary of MyAbstractClass objects.

public class MyChildClass : MyAbstractClass { ... }
public class MyChildClass2 : MyAbstractClass { ... }

private Dictionary<string, MyChildClass> _dictionary;

public Dictionary<string, MyAbstractClass> Dict
{
get { return _dictionary; } //error: no implicit conversion.
}

Now, outside this class, you say

Dictionary<string, MyAbstractClass> theDictionary = myObject.Dict;
theDictionary["Bruce"] = new MyChildClass2(...);

That last line seems perfectly legal to the compiler, but would have to
fail at runtime, because the actual dictionary returned by
myObject.Dict is not a dictionary of "anything that inherits from
MyAbstractClass". It is, rather a dictionary of a specific subclass of
MyAbstractClass, called MyChildClass.

By allowing the return of a dictionary of a class farther up the
hierarchy, you've lost compile-time type safety, which is what generics
are trying to give you in the first place.
 
Brian P said:
I want to expose a property of Dictionary<string, MyAbstractClass>.

I tried to do it this way:

private Dictionary<string, MyChildClass> _dictionary;

public Dictionary<string, MyAbstractClass>
{
get { return _dictionary; } //error: no implicit conversion.
}

How can I have a privay dictionay that uses an inheritied class, but
expose that dictionary as the base type?
Click to expand...

You can't. There's no covariance like that on generic types. If you
could do that, consider the following code:

Dictionary<string, MyAbstractClass> foo = YourProperty;
MyOtherChildClass bar = new MyOtherChildClass();
foo["hello"] = bar;

Now, the actual dictionary is only meant to contain MyChildClass values
- but I've just broken that!
 
Jon said:
You can't. There's no covariance like that on generic types. If you
could do that, consider the following code:

Dictionary<string, MyAbstractClass> foo = YourProperty;
MyOtherChildClass bar = new MyOtherChildClass();
foo["hello"] = bar;

Now, the actual dictionary is only meant to contain MyChildClass values
- but I've just broken that!
Click to expand...


I must be doing something wrong in my design / thinking.

To the outside world, I want the Dictionary<string, MyAbstractClass> to
be "read-only". So, I guess I'm not worried about the problem you point
out.


But, I realize that I'm surely doing something poor:

I have an interface that several classes implement. The interface
requires Dictionary <string, MyAbstractClass>. But the classes that
implement that interface, their interal workings are going to use
ChildClasses of MyAbstractClass. And so long as the only usage of
ChildClasses are interally, I can't see how exposing the dictionary as
MyAbstractClass is "bad".


--Brian
 
Jon said:
You can't. There's no covariance like that on generic types. If you
could do that, consider the following code:

Dictionary<string, MyAbstractClass> foo = YourProperty;
MyOtherChildClass bar = new MyOtherChildClass();
foo["hello"] = bar;

Now, the actual dictionary is only meant to contain MyChildClass values
- but I've just broken that!
Click to expand...


I must be doing something wrong in my design / thinking.

To the outside world, I want the Dictionary<string, MyAbstractClass> to
be "read-only". So, I guess I'm not worried about the problem you point
out.


But, I realize that I'm surely doing something poor:

I have an interface that several classes implement. The interface
requires Dictionary <string, MyAbstractClass>. But the classes that
implement that interface, their interal workings are going to use
ChildClasses of MyAbstractClass. And so long as the only usage of
ChildClasses are interally, I can't see how exposing the dictionary as
MyAbstractClass is "bad".


--Brian
 
Brian P said:
I must be doing something wrong in my design / thinking.

To the outside world, I want the Dictionary<string, MyAbstractClass> to
be "read-only". So, I guess I'm not worried about the problem you point
out.
Click to expand...

Okay - but there's nothing to stop clients from *trying* to do that.
You're not exposing it in a read-only way (not that I can see any read-
only interfaces that are easily exposed in the generic collections
provided by the framework...)
But, I realize that I'm surely doing something poor:

I have an interface that several classes implement. The interface
requires Dictionary <string, MyAbstractClass>. But the classes that
implement that interface, their interal workings are going to use
ChildClasses of MyAbstractClass. And so long as the only usage of
ChildClasses are interally, I can't see how exposing the dictionary as
MyAbstractClass is "bad".
Click to expand...

I entirely understand where you're coming from, but I can't immediately
think of any way of doing it with generics.

Do the internal workings definitely need to know they they'll be using
ChildClass, other than when they're putting the entries in?
 
I must be doing something wrong in my design / thinking.

To the outside world, I want the Dictionary<string, MyAbstractClass> to
be "read-only". So, I guess I'm not worried about the problem you point
out.
Click to expand...

I've thought of an alternative. Rather than exposing a whole
Dictionary<string,MyAbstractClass> would it be possible to expose just
a property:

public MyAbstractClass this[string key];

? You could easily implement that in your class, just by returning
_dictionary[key]; and you'd be guaranteed that it would be exposing it
in a read-only way.


Alternatively, you could have:
class ReadOnlyDictionary<K,V1,V2> : IDictionary<K,V1>
where V2 : V1
{
Dictionary<K,V2> dictionary;

public V1 this [K key]
{
get { return dictionary[key]; }
set { throw new UnsupportedOperationException(); }
}

// etc - implement the rest of the appropriate IDictionary
// properties
}

You could then use:

public IDictionary<string, MyAbstractClass>
{
get { return new
ReadOnlyDictionary<string, MyAbstractClass, ChildClass>
(dictionary);
}

I *think* that would work - and would actually be quite neat (and very
reusable). You could do the same for List if you ever needed to.

My guess is that *someone* has actually already done this and published
it as open source... I can't be the first to think of it.
 
Jon said:
I entirely understand where you're coming from, but I can't immediately
think of any way of doing it with generics.
Click to expand...

=) so I'm not completey dumb.

Do the internal workings definitely need to know they they'll be using
ChildClass, other than when they're putting the entries in?
Click to expand...

Yes, they do. So, for now, I have a private dictionary of <string,
MyAbstractClass> and in the internal workings, I cast to MyChildClass:

((MyChildClass)_myDictionary["foo"]).ChildSpecificPropertyOrMethod


This lets me expose the dictionary as MyAbstractClass but I still can
"work" with the ChildClass internally. Though, I admit this doesn't
seem ideal.

--Brian
 
Jon said:
I've thought of an alternative. Rather than exposing a whole
Dictionary<string,MyAbstractClass> would it be possible to expose just
a property:

public MyAbstractClass this[string key];

? You could easily implement that in your class, just by returning
_dictionary[key]; and you'd be guaranteed that it would be exposing it
in a read-only way.

I *think* that would work - and would actually be quite neat (and very
reusable). You could do the same for List if you ever needed to.

My guess is that *someone* has actually already done this and published
it as open source... I can't be the first to think of it.
Click to expand...


Yes! This sounds perfect! You are awesome ... I see you all over these
newsgroups and I always read your posts. Most of the time you are
talking about things over my head, but I usually learn something new
from you.

Thanks again,

--Brian
 
Back
Top