System.Array and IList - language/framework design question

  • Thread starter Thread starter emma middlebrook
  • Start date Start date
E

emma middlebrook

Hi

Straight to the point - I don't understand why System.Array derives
from IList (given the methods/properties actually on IList).

When designing an interface you specify a contract. Deriving from an
interface and only implementing some of it means something is wrong:
either the interface specification is wrong e.g. not minimal or the
derivation is wrong e.g. the type can't actually honour this contract.

Firstly, an array is fixed size so it doesn't make sense for it to
implement Add/Remove methods anyway (these appear on IList). So, they
throw exceptions but I don't think that Array should even need to be
implementing these in the first place!

Secondly, for an array, what does IList provide that System.Array
would not have otherwise? *Nothing* as far as I can see. So what's it
there for?

Thirdly, I think the actual current implementation is half-baked
anyway. For instance, get an IList from an Array with some objects and
call Clear. Then call Count. Then notice that Count isn't 0 - it
hasn't been synched by Clear. I realise that the specification of
Clear doesn't require this (see the docs) but still, you'd expect it
here.

Fourthly, I think the IList property IsFixedSize is strange. If a data
structure is fixed size it shouldn't have to implement Add/Remove
methods because it doesn't make sense. So there should be two separate
interfaces for fixed size data structures and for variable size data
structures.

These are just my ideas using really basic design guidelines. I'm
probably missing something or not seeing the full picture so some help
in this direction would be useful!

Thanks

Emma Middlebrook
(e-mail address removed)
 
You should've started with the 4th item because an answer to it would kind
of eliminate #1. The fact that they made one interface instead of two - I'd
say it's just a matter of taste. I kind of like having one, - less hassle
when you need to find out if the collection is readonly - no need to query
another interface. Besides, IList has a good description, as documentation
states - "Represents a collection of objects that can be individually
accessed by index.". I think the design does not contradict the description.

I don't quite understand what's that confusing about #2? The fact that Array
is implementing IList is just a matter of followind the pattern - all
collection classes in .NET implement either/some/all of these: IEnumerable,
ICollection, IList. And some pieces of functionality are based on using the
interfaces. For instance you can bind Array or ArrayList to a grid because
they both expose IList...

As far as #3 goes - well contains the answer, doesn't it? The docs say:
"Implementations of this method can vary in how they handle the
ICollection.Count and the capacity of a collection. Typically, the count is
set to zero. The capacity can be set to zero or a default value, or it can
remain unchanged." Hmmm.... In this particular implementation, calling Clear
doesn't change Count.... but that's documented, right? :)

Sincerely,
Val.
 
From what you're saying, Val, I don't see how you could criticize an
interface like this one:

public interface IBoxer {
bool IsCerealBoxer {get;}
bool IsAthleticBoxer {get;}
bool IsCanineBoxer {get;}

void FillCerealInBox();
void MoveAssemblyLine();
void Yawn();

void RightPunch();
void LeftJab();
void BiteEar();

void Bark();
void PlayDead();
void Shake();
}

My point is that things that are different should be in different
interfaces. Read only arrays and variable size arrays have many things in
common. So do cereal boxers with athletic boxers. (Both are human, both have
jobs, etc.) But they don't have enough in common to warrant putting them in
the same interface.

I'm with ya, emma.

Chris
 
I see your sarcazm, but I don't think your example is good enough, Chris.
You mention commonalities in your comments only. They're not expressed in
the desing at all. It is pretty normal that a list can be expanded or be of
a fixed size. It is also possible that a list can change behaviour with
time - become readonly for instance. On the other hand I don't think that
its pretty commong for a cereal boxer to bite ears off on the ring, or for
a doggy to end up yawning at an assembly line.

Well, here is an extreme of "correct" design that you guys will probably
like:

public interface IAthleticBoxer
{
void RightPunch();
}

public interface ICoolAthleticBoxer : IAthleticBoxer
{
void LeftJab();
}

public interface IMTysonKindOfBoxer : ICoolAthleticBoxer
{
void BiteEar();
}


Do you think there's something wrong with it (a hint - there is)?

Val.
 
yes, you're right. the current .NET collection structure is very stupid.

much better would be following structure:

interface IReadOnlyList
{
Prev();
Next();
Count();
}

interface IReadOnlyArray : IReadOnlyList
{
GetAt(); // indexer
}

interface IArray : IReadOnlyArray
{
SetAt(); // indexer
}

interface IList : IReadOnlyList
{
Add();
Remove();
Insert();
Clear();
}

interface IArrayList : IArray, IList
{
}

this is imho the perfect solution. there is an interface for every need
and it is still kept simple. and dont't understand why microsoft solved
it in such a stupid manner.
 
Back
Top