Why not VB6 style collections in .Net?

[Considered]

Hello everyone,

I just found this forum today - nice to meet you all in advance!

I hope that some enlightened programmer here can really help me out

...A few years ago I cross-trained myself from VB6 to VB.Net. I was the only VB developer and had very little time to do this (employer's orders) so I bought a book by Francesco Balena and proceeded to make the transition at the speed of light. The very first thing I thought was "right... how do I do classes and collections". So I got classes, no problem... But when I came to look at collections I found I had several options:

• Lists
• ArrayLists
• Dictionaries
• Hash Tables

...I looked at the definitions of each one, decided they were limited in comparison to VB6 style collections, so I figured out how to code the VB6 style collection in VB.Net and wrote it all the "old-fashioned" way. I couldn't understand why they weren't an option in the book? But I didn't have time to contemplate it...

So, a few years down the line I, finally, have some breathing space - and I'm taking this time to go back through VB.Net, from first principles, to make sure I didn't miss anything important along the way. I've been reading a book called "Mastering Microsoft Visual Basic" and have come to the section about "collections" - I've found the same 4 options as before:

• Lists
• ArrayLists
• Dictionaries
• Hash Tables

So...

I'm not too concerned about Lists and ArrayLists - basic collections of information without a key aren't usually "proper objects" in my experience - and I always store collections of objects with keys as a force of habit.

Dictionaries look ok, and, on fairly quick contemplation, they trump Hash Tables because they're typed.

...my question is - why have we stopped using "Collections" (like VB6 collections) at all? Why don't the books mention them? Why do I hear a general concensus in C# and VB.Net circles that they're redundant?

When I write an application with collections of objects I generally like to write a "ReadAll" function, and have had many experiences where it's been advantageous to apply a procedure to the complete collection. So, in my mind (as it stands) it makes sense to have an object which has space to group any necessary procedures with the collection. And I thought this was one of the principles of Object Orientated Development? Sure I could achieve the same thing by having a Dictionary inside a class...but if I'm going to do that, wouldn't it make sense to write a VB6 style collection?

You're thoughts are more than welcome here.

(Sorry that went on a bit... I just wanted to give a background on why I might have missed that in the first place, and where I've got to today )

I also prepared to have my thinking changed on this, it's just, that, at the moment I can't see any reason to move away from the old-fashioned VB6 style collection.

Many thanks in advance from a humble "VB6 style VB.Net programmer"

 

[jmcilhinney]

The single responsibility principle basically states that classes and members should each do one thing and do it well. VB6 was fond of creating super-classes that bundled together a whole lot of related functionality, e.g. Winsock, Inet and Recordset. Collections are similar. In .NET there are numerous collection classes and each one behaves differently and is suitable for a different set of requirements. You determine your requirements and use the appropriate collection class for that. You have all the functionality that you need and none that you don't.

By the way, using a keyed collection out of habit is really pointless. I would say that I would use the List class probably 20 times more often than a Dictionary.

 

[Considered]

using a keyed collection out of habit is really pointless.

If you write an application that does data entry/manipulation, do you never hold all the objects in memory?

 

[jmcilhinney]

I didn't say that I never use a keyed collection. What I said was that using a keyed collection when you don't need to is pointless. If you need a key then you should use a keyed collection but, in my experience, that is the exception rather than the rule.

 

[Considered]

Ok, I see...

I've always used them because it seemed to me that you might as well start off with an approach that covered all possibilities of scale...

Then there's no need to bother refactoring, or being concerned about double-standards throughout the code...

Are they extrememly memory intensive in comparison?

 

[jmcilhinney]

That's exactly the VB6-style approach I was talking about that violates good OOP practice. You're saying that you use something as general as possible just in case. The proper OO approach is to use just what you need. If you need something different then use something different.

 

[Considered]

Ok, let me give you my thinking on that...

Lets say you'd written an off-the-shelf product for prestigious manufacturing companies like Rolls-Royce, and that this solution was critical to the day-to-day running of their manufacturing facilities... i.e. one fault and the entire process comes to a stop (in view of taking full responsibility, lets discount the "theory" that they have a backup plan to deal with it).

Now, lets say in this application there are references to 50 different types of collections of objects.

In the future it's possible that we might want to add a generic function to each collection type. In that case it would be better to have each type of collection encapsulated within it's own object... thereby eliminating dupliated code, and providing a lot of clarity by having the collection's methods contained with the collection itself.

Otherwise, if this does happen in the future we'll need to move the collection into its own object AND write the required procedure(s) to go with it... which is a lot more that can potentially go wrong than simply writing new procedure(s) to do with it. You're potentially then going to need to change all calls to the object.

Doesn't that seem like a good reason to write everything with as much potential as possible?

Or are we talking in a difference of scale of application?

......this is why I'm wondering; is a collection much more "expensive" than other types of "collections" i.e. Lists etc?

If they're not - why not use 'em?

I mean - if a Bentley Flying Spur cost a similar price to a Chrysler 300C, and they cost a similar price to run, then you'd be a bit barmy to buy the Chrysler... or are we, really, talking about something completely unlike that here?

 

[jmcilhinney]

I'm not going to keep repeating myself. You can do what you like, when you like but good practice dictates that you use the most appropriate tool for the job. If you have good reason to suspect that a future change will require you to use something else then it's not unreasonable to write your code with that change in mind. If you're just using a more complex class in case it might be needed in the future with no specific reason for believing that it will then you're not following best practice. It's that simple. If I know I need to knock a nail into a wall, I don't take a sledge hammer just in case I might need to break rock. If you need a sledge hammer the use a sledge hammer. If you can only carry one tool and you have good reason to believe that you'll need a sledge hammer at some point then use a sledge hammer. If all you need is a claw hammer and there's no direct evidence that you'll need anything else but a claw hammer then to use anything but a claw hammer is just not right. You can still knock a nail in with a sledge hammer if you want to and not break anything but it's not the "right" thing to do.

 

[JohnH]

In the future it's possible that we might want to add a generic function to each collection type. In that case it would be better to have each type of collection encapsulated within it's own object... thereby eliminating dupliated code, and providing a lot of clarity by having the collection's methods contained with the collection itself.

If that is likely I'd say you should start off inheriting from one of the base collection types, for example Collection(Of T) or KeyedCollection(Of T), and later add the generic method to your collection type.