Wrox Programmer Forums
Go Back   Wrox Programmer Forums > .NET > Other .NET > General .NET
|
General .NET For general discussion of MICROSOFT .NET topics that don't fall within any of the other .NET forum subcategories or .NET language forums.  If your question is specific to a language (C# or Visual Basic) or type of application (Windows Forms or ASP.Net) try an applicable forum category. ** PLEASE BE SPECIFIC WITH YOUR QUESTION ** When posting here, provide details regarding the Microsoft .NET language you are using and/or what type of application (Windows/Web Forms, etc) you are working in, if applicable to the question. This will help others answer the question without having to ask.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the General .NET section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old January 17th, 2006, 07:34 AM
Authorized User
 
Join Date: Aug 2004
Posts: 20
Thanks: 0
Thanked 0 Times in 0 Posts
Default Modifying collection properties

I'm wondering what is the best way for a class with a collection type property to discover when that collection has been modified. Before delving into this I'll try to explain what I'm trying to achieve by describing a similar situation which doesn't involve collections.

We might have a ContainedClass and a ParentClass which has a property of type ContainedClass. The ContainedClass has some property (eg Name) that the ParentClass needs to know about. Typically you would deal with this by adding a NameChanged event to the ContainedClass which the Parent class handles.

Whenever the ParentClass.ContainedClass property changes the ParentClass will need to unhook its event handler from the old instance of the ContainedClass and hook on to the same event for the new instance. To do this (and following the Component/Control style approach) we could write OnContainedClassChanging and OnContainedClassChanged functions in the ParentClass to be called during the ParentClass.ContainedClass property's set function. These would respectively remove and add an event handler to the current ContainedClass member variable.

Now, what if instead the ParentClass has a collection property, for example of type ContainedClassCollection, and needs to know when the Name property changes for any of this collection's items? The ParentClass could still handle the NameChanged event, but the question is when would the event handlers be added and removed.

One way I can think of doing it is for the collection itself to have ItemAdded and ItemRemoved events which the ParentClass would handle. For example, whenever the ItemAdded event was handled the ParentClass could find the new member and add a handler for its NameChanged event. However, none of the standard .net collection classes have events like this, so it leads me to believe that doing it this way is not recommended practice.

An alternative way is to have the collection property be read only (at least for clients of the ParentClass) and instead create explicit AddContainedClass/RemoveContainedClass functions on the ParentClass which do the necessary event handler manipulation and modify the collection. The problem with this approach is that you end up repeating the collection related functions of the collection on the ParentClass interface, which is bad design because it makes it look like the ParentClass itself is some kind of collection object when it isn't, and also could get rather involved once you start needing to add AddRange, RemoveRange, Clear, etc. functions - each one of these would require some event handler manipulation.

Does anyone have any recommendations or experience on what might be best practices, or point me to some resources on the subject?

Thanks

 
Old January 17th, 2006, 10:40 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 453
Thanks: 0
Thanked 1 Time in 1 Post
Send a message via AIM to Ankur_Verma Send a message via MSN to Ankur_Verma
Default

First of all I would like to thank you for presenting your query so fantastically. I’m saying so because it really is a pleasure seeing somebody having regards for the people here who are willing to help. This is a perfect example of what I mean when I request people to present their queries the way they would want them to be presented to themselves.

About your query,

Well Eadred, I think the last alternative indeed seems to be the only alternative left here.

But you can improve upon the design and save yourself some effort if you choose not to implement the Add/Retrieve/Remove functions in the ParentClass but write a different class instead that extends one of the collection classes and use this new class’s objects as the property of ParentClass.

In this new class you just have to call the base class’s relevant functions to perform Add/Retrieve/Remove etc. But before you call the base class’s function you have a chance of triggering an event to let the ParentClass know that the property is being changed.

If you develop this new class into a generic class, you actually will be creating a collection class that you can use anywhere. It will work like the collection class it extends but would be capable to letting the user know when its contents are being changed.

If you are working on VS 2005, you would find implementing the collection interfaces and classes particularly easy as VS 2005 has a lot of support for auto generation of expected or commonly used pieces of codes.

Hope this helps.

Regards
Ankur
 
Old January 17th, 2006, 11:12 AM
Authorized User
 
Join Date: Aug 2004
Posts: 20
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thank you for comments - its nice to be appreciated :)

It seems what you are suggesting is actually my first option, ie writing a custom collection class which raises relevant events on top of maintaining the internal collection of objects, and personally this would be my preferred way of doing things.

I'm just surprised that this approach isn't more widespread, although I have seen that there is a CollectionChangeEventArgs class which is used by events defined by some of the DataSet related classes (like DataColumnCollection).

By the way, because I am working with .Net 1.1 without the benefit of Generics I tend to implement my custom collections by writing a wrapper around a standard collection, rather than inheriting from it, so that I can write an Add function (etc) that is type safe (ie doesn't accept any old Object as a parameter).

I was wondering whether there is a dedicated forum for OO design and best practices issues like this?

Regards

Eadred

 
Old January 17th, 2006, 12:57 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 453
Thanks: 0
Thanked 1 Time in 1 Post
Send a message via AIM to Ankur_Verma Send a message via MSN to Ankur_Verma
Default

Cant really say which is the best forum for OO
discussions. This, however, is also an issue of
what’s available and whets not on .NET 1.1 as it
all came down to writing a type safe Add
function which you wouldn’t have to do if you
were using .NET 2.0.

Anyways, its a better approach that you are
taking here, but I've to say if you are not
working on VS 2005 your are missing out on a lot.

Regards
Ankur Verma





Similar Threads
Thread Thread Starter Forum Replies Last Post
setting Collection properties for user control PurpleHaze VS.NET 2002/2003 2 December 30th, 2008 02:41 AM
modifying Webshop mlevans BOOK: ASP.NET 2.0 Instant Results ISBN: 978-0-471-74951-6 3 September 23rd, 2006 05:12 AM
Modifying XML enderjs XML 0 October 7th, 2004 10:29 AM
ADOX MSDASQL Access Properties Collection is EMPTY Xentrax Access 0 May 27th, 2004 10:36 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.