Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Converting Collections to Arrays ?

 
dean tomlinson
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A good example of my issue can be seen in the critieriaFind method. In this I add matching records to a dynamic sized collection such as a Vector.
Once the number of matches has been finalised, I then create an array of DataInfo objects - I know this is a requirmeent of the criteriaFind method anyway, so this was a bad axample.
A better exapmle, I have a method called getFlightOrigins that the gui layer uses. the return type of this method is a String array, but inside the method I am using a temporary dynamic collection such as a Vector, and then crete my fixed sie array depending on the number of different flight origins found.
Is this a waste of time, should we just be returning a collection, and letting the client iterate through it, and cast each element into the type it is expecting - even though this cannot be explicitlely seen from the method signature.
Does anyone agree that it is better to return an array of a specific class/interface types, even though additional time has been spent.
Thanks for any ideas / opinions ...
 
Rajesh Matti
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deanos - My approach is that classes should be as generic as possible and exposed methods should be as specific as possible. Hence, I feel that returning an array of a specific class is better than returning a collection.
Hope this helps.
-Rajesh
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your approach is right, Have the method create the HashSet, then copy it to an array that is passed back from the method.
Here's an example of the bet code to use
 
Peter Bugla
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd return a collection interface (as general as possible,e.g. List) and (of course) put a statement in the JavaDoc comment of the method, what is actually returned (e.g. a List of House objects associated with the provided Owner parameter). So a programmer that uses your API can easily see, what he gets and you can profit from good encapsulation (see below).
BTW: Even if you return a House[] you should mention, what Houses you return (specify the semantics).
It's generally a good thing to keep the interfaces of your classes, your components, your programs, ... as small and as general as possible, (i.e. the level of encapsulation as high as possible).
The reason for this is simple:
Even if you don't expect that it might become necessary in the future to make changes on the class, component, ... later or if you don't expect that someone else will program anything using your classes, components, ... it might just happen.
"Worst case" (not that bad really, if you think about it ): You programmed something, (many) other programmers actually used it (using the available interfaces) and the necessity for significant changes in your classes, ... arises.
case 1: you offered only a very small and general interface --> no problem, you can change everything internally and you (most likely) don't need to change the interface
case2: you offered a broad and/or very specific interface --> if you change anything significant, it will (most likely) break your interface and all the points where you're interface has been used must be changed (causing a lot of anger ... leads to hate leads to suffering ... and of course $$$)
(Another more specific advantage of collection types is the possibility to use iterators, giving the user of the object a way to avoid getting all data at once. This sometimes gets important if you use distributed applications and / or large databases.)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic