I assume you are asking about the general condition where you are defining a method
that needs to have more than 4 or so arguments
passed to it, so I'll approach it that way.
I'm not a fan of passing arrays for something like that. Here's why:
1. You lose type safety. Your example is a rare occurrence in that all args are
strings. You'll be using object[] more often than
not.
2. You lose intellisense in the IDE. Well, you'll still have it, but what help is it
when "object[] value" pops up?
3. Opens the door for way too many subtle mistakes to creep in, and no way to catch
them at compile time. Bugs found at runtime are
very expensive. Both in the problems they may have caused before they are found, and
in the fix and redist costs.
4. Adds complexity and extra work to all consumers of the method, because they'll have
to manually ensure the content and ordering
of the array elements matches up with the content and ordering expected by the method
designer. Off-by-one errors will happen even
then. It's Murphy's Law.
A good library designer reduces the amount of effort for a consumer, not increases it.
You should create a struct or class that has members defining the values the method
needs, and make that the data type for the
parameter to the method. If you look at the Win32 API, this is the design pattern used
(for the most part). Same thing for the .Net
BCL.
For a more robust implementation define and use an interface. Either way you decide to
do it will be a massive improvement over
using an array.
For example:
//The interface
public interface IContactInfo {
public string LastName;
public string FirstName;
//... etc...
}
//Library designer supplied impl of the IContactInfo interface
public struct ContactInfo : IContactInfo {
//IContactInfo member definitions here
public string LastName;
... etc.
}
//A possible library consumer's impl of the IContactInfo interface.
//Adds some customer specific behaviors
public class CustomerContactInfo : IContactInfo {
//IContactInfo member definitions here
public string FirstName;
//... etc...
//Customer specific member definitions and methods here
public Guid CustId;
//... etc...
}
//Much cleaner and more flexible AddUser() method
public string AddUser(IContactInfo contactInfo) {
//Do work. For example,
//return first + last name
return (contactInfo.FirstName
+ " "
+ contactInfo.LastName
);
}
Keep Smilin'
Ed Stegman
-----Original Message-----
From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of
Stephen Patten
Sent: Friday, May 31, 2002 2:55 PM
To: [EMAIL PROTECTED]
Subject: Best Practice for Passing Arguments
Hi All,
Just wondering if there is a better way to pass arguments around than the
way I am right now(code posted at end of messsage). This one happens to be
all strings so I guess a Array or ArrayList might suffice, but what if the
values are of different types? Any help would be appreciated.
Thank you,
Stephen
ASPX Page Originally From IBuySpy Portal >>>>>
// Add the info to the database
UsersDB users = new ASPNetPortal.UsersDB();
if ((users.AddUser
(UserIdentificationControl.UserAgencyValue,
UserIdentificationControl.UserBadgeID,
UserIdentificationControl.UserLastName,
UserIdentificationControl.UserFirstName,
UserIdentificationControl.UserTitle,
UserContactControl.UserAddress1,
UserContactControl.UserAddress2,
UserContactControl.UserAddress3,
UserContactControl.UserCity,
UserContactControl.UserStateValue,
UserContactControl.UserZip,
UserContactControl.UserOfficePhone,
UserContactControl.UserMobilePhone,
UserContactControl.UserOfficeFax,
UserContactControl.UserPager,
UserEmailControl.UserEmailWork,
UserEmailControl.UserEmailHome,
UserSOWControl.UserScopeValue,
UserFunctionalGroupControl.UserFGroupValue)) == "99")
....rest of code removed
Database Component >>>>>>
public string AddUser(String userAgencyID, String
badgeTaxID,
String lastName, String firstName, String jobTitle,
String address1, String address2, String address3,
String city, String stateID, String zipCode,
String officePhone, String officeFax,
String mobilePhone,String pagerNumber,
String emailWork,String emailHome,
String sow, String fgroup)
....rest of code removed
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
