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.
"Chris Capel" <chris@nowhere.com> wrote in message
news:%23zb%237ZQXDHA.1640@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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[/color]
have[color=blue]
> jobs, etc.) But they don't have enough in common to warrant putting them[/color]
in[color=blue]
> the same interface.
>
> I'm with ya, emma.
>
> Chris
>
> "Val Savvateev" <ovsavvateev@meridium.com_NO_SPAM> wrote in message
> news:#ufJQhPXDHA.2620@TK2MSFTNGP09.phx.gbl...[color=green]
> >
> > "emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
> > news:e27ae805.0308062259.27004866@posting.google.c om...[color=darkred]
> > > "Val Savvateev" <vsavvateev@meridium.com_NO_SPAM> wrote in message[/color]
> > news:<uM2xNv3WDHA.2256@TK2MSFTNGP10.phx.gbl>...[color=darkred]
> > > > You should've started with the 4th item because an answer to it[/color][/color][/color]
would[color=blue][color=green]
> > kind[color=darkred]
> > > > of eliminate #1. The fact that they made one interface instead of[/color][/color]
> two -[color=green]
> > I'd[color=darkred]
> > > > say it's just a matter of taste. I kind of like having one, - less[/color]
> > hassle[color=darkred]
> > > > when you need to find out if the collection is readonly - no need to[/color]
> > query[color=darkred]
> > > > another interface. Besides, IList has a good description, as[/color]
> > documentation[color=darkred]
> > > > states - "Represents a collection of objects that can be[/color][/color][/color]
individually[color=blue][color=green][color=darkred]
> > > > accessed by index.". I think the design does not contradict the[/color]
> > description.[color=darkred]
> > >
> > > I don't believe it's a matter of taste - an interface has an implicit
> > > contract. You can't argue that because the documentation says it can
> > > be used to access by index then it's OK. IList has semantics suitable
> > > for data structures whose size can vary.[/color]
> >
> > Not quite correct... Let's put it this way - IList sematics show that it[/color]
> can[color=green]
> > be applied to structures of variable _or_ fixed size (depending on the[/color]
> value[color=green]
> > of IsFixedSize property). The structures could also be readonly (you can[/color]
> or[color=green]
> > cannot update particular elements based on the value of IsReadOnly
> > property). I think you underestimate the presense of the mentioned
> > properties. Also, isn't it logical after all that if you can update
> > particular elements using an interface then you also should be able to
> > add/remove the elements through the same interface....
> >[color=darkred]
> > > If this interface was aimed
> > > at fixed size[/color]
> >
> > It was not. That's the point.
> >[color=darkred]
> > > data structures then it's clearly wrong because fixed
> > > size data structures cannot be expected to implement some of its
> > > members e.g. Add/Remove!![/color]
> >
> > See value of IsFixedSize. I dont see any problem with that.
> >[color=darkred]
> > > So, anyway, the IList itself is fine. It's
> > > just not appropriate to derive an Array from it.[/color]
> >
> > Hmm... "just not apporpriate" is not quite an argument... Why not
> > appropriate?
> >[color=darkred]
> > > Some of the
> > > functionality you say you like should be factored out as it's
> > > orthogonal functionality to a list and maybe common to all data
> > > structures. Then there'd be nothing wrong with Array and other
> > > collections deriving from that new interface.[/color]
> >
> > Well... I see your point, and it would be valid if the interface was[/color]
> missing[color=green]
> > the two properties. I still think it was just matter of taste and let me
> > illustrate why. If the design was your way it would contain two[/color][/color]
interfaces[color=blue][color=green]
> > (or more) instead of single IList, something like this (pseudo-code):
> >
> > IList
> > {
> > obect Item(index) {set;get;}
> > int IdexOf(item)
> > bool Contains(item)
> > bool IsReadOnly
> > }
> >
> > IListManager
> > {
> > Add()
> > Insert()
> > Remove()
> > Clear()
> > ....etc
> > }
> >
> > Now imagine, I'm implementing my own datagrid. The grid should be[/color][/color]
editable[color=blue][color=green]
> > and allow for deleting and adding items based on whether the list is
> > fixedsize.
> > My initialization code for both designes would be different... but just
> > alittle........
> >
> > In case of the proposed design:
> > Init(object source)
> > {
> > IList _items = source as IList;
> > IListManage _manager = source as IListManager;
> > bool _isFixedSize = (_manager != null);
> > }
> >
> > In case of the current design I would not need to query for the manager
> > interface and I would just use properties on IList:
> >
> > Init(object source)
> > {
> > IList _items = source as IList;
> > }
> >
> >
> > Datagrid would also be a good argument for having everything in one
> > interface - when you see list of items on the screen it's either[/color][/color]
editable[color=blue]
> or[color=green]
> > not (IsReadOnly) and you either can add/remove items or not
> > (IsFixedSize)..... "Manageability" of the list does not disprove the[/color][/color]
fact[color=blue][color=green]
> > that it's just a list....
> >[color=darkred]
> > > > I don't quite understand what's that confusing about #2? The fact[/color][/color][/color]
that[color=blue][color=green]
> > Array[color=darkred]
> > > > is implementing IList is just a matter of followind the pattern -[/color][/color][/color]
all[color=blue][color=green][color=darkred]
> > > > collection classes in .NET implement either/some/all of these:[/color]
> > IEnumerable,[color=darkred]
> > > > ICollection, IList. And some pieces of functionality are based on[/color][/color]
> using[color=green]
> > the[color=darkred]
> > > > interfaces. For instance you can bind Array or ArrayList to a grid[/color]
> > because[color=darkred]
> > > > they both expose IList...
> > >
> > > I'm not confused, it just seems wrong. What is your pattern - you just
> > > say some collections implement some interfaces?[/color]
> >
> > Yep.... Ultimately all the collections in the library implement[/color]
> IEnumerable[color=green]
> > (ICollection iherits IEnumerable, IList iherits ICollection) :
> >
> >[/color]
>[/color]
http://msdn.microsoft.com/library/en...collectionsien[color=blue]
> umerableclasstopic.asp?frame=true[color=green]
> >[color=darkred]
> > > Binding ... would
> > > explain a little further for my own education how this works and the
> > > importance of IList in this - that would be appreciated as I don't
> > > know much about binding.[/color]
> >
> >[/color]
>[/color]
http://msdn.microsoft.com/library/en...windowsformsda[color=blue]
> tagridclassdatasourcetopic.asp?frame=true[color=green]
> >
> > IList is the simplest structure that can be used in binding...
> >[color=darkred]
> > > > As far as #3 goes - well contains the answer, doesn't it? The docs[/color][/color]
> say:[color=green][color=darkred]
> > > > "Implementations of this method can vary in how they handle the
> > > > ICollection.Count and the capacity of a collection. Typically, the[/color][/color]
> count[color=green]
> > is[color=darkred]
> > > > set to zero. The capacity can be set to zero or a default value, or[/color][/color][/color]
it[color=blue][color=green]
> > can[color=darkred]
> > > > remain unchanged." Hmmm.... In this particular implementation,[/color][/color][/color]
calling[color=blue][color=green]
> > Clear[color=darkred]
> > > > doesn't change Count.... but that's documented, right? :)
> > >
> > > Yes, I know but I still think that's bad, documented or not![/color]
> >
> > Well, you see, I told ya! - just a matter of taste ("i know, but...")[/color][/color]
....[color=blue]
> :)[color=green]
> >
> > List the discussion....
> >
> > Val
> >[color=darkred]
> > >
> > > Cheers for your comments and discussion - I'm just saying really that
> > > the IList interface should be factored out so Array can derive from
> > > nicely defined interfaces each of which asks it to implement methods
> > > that it can actually do!
> > >
> > > Emma Middlebrook
> > >
emma_middlebrook@fastmail.fm
> > >
> > > > Sincerely,
> > > > Val.
> > > >
> > > > "emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
> > > > news:e27ae805.0308050816.73657480@posting.google.c om...
> > > > > Hi
> > > > >
> > > > > Straight to the point - I don't understand why System.Array[/color][/color][/color]
derives[color=blue][color=green][color=darkred]
> > > > > from IList (given the methods/properties actually on IList).
> > > > >
> > > > > When designing an interface you specify a contract. Deriving from[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> > > > > interface and only implementing some of it means something is[/color][/color][/color]
wrong:[color=blue][color=green][color=darkred]
> > > > > either the interface specification is wrong e.g. not minimal or[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > derivation is wrong e.g. the type can't actually honour this[/color][/color]
> contract.[color=green][color=darkred]
> > > > >
> > > > > 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,[/color][/color]
> they[color=green][color=darkred]
> > > > > throw exceptions but I don't think that Array should even need to[/color][/color][/color]
be[color=blue][color=green][color=darkred]
> > > > > 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[/color][/color]
> it[color=green][color=darkred]
> > > > > there for?
> > > > >
> > > > > Thirdly, I think the actual current implementation is half-baked
> > > > > anyway. For instance, get an IList from an Array with some objects[/color][/color]
> and[color=green][color=darkred]
> > > > > 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[/color][/color][/color]
it[color=blue][color=green][color=darkred]
> > > > > here.
> > > > >
> > > > > Fourthly, I think the IList property IsFixedSize is strange. If a[/color][/color]
> data[color=green][color=darkred]
> > > > > structure is fixed size it shouldn't have to implement Add/Remove
> > > > > methods because it doesn't make sense. So there should be two[/color][/color]
> separate[color=green][color=darkred]
> > > > > interfaces for fixed size data structures and for variable size[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > > > structures.
> > > > >
> > > > > These are just my ideas using really basic design guidelines. I'm
> > > > > probably missing something or not seeing the full picture so some[/color][/color]
> help[color=green][color=darkred]
> > > > > in this direction would be useful!
> > > > >
> > > > > Thanks
> > > > >
> > > > > Emma Middlebrook
> > > > >
emma_middlebrook@fastmail.fm[/color]
> >
> >[/color]
>
>[/color]
