I have some incredibly old code that is going to be refactored. I have a lot of options to archive emails. The core algorithm for handling the archiving is like:
'get options into an options class
MailParser parses the emails of a mailbox and then writes the emails to Valentina, PDF or Filemaker. As result I’m always carting too many parameters around in classes. For instance, in MailParser I write the mailbox Factory style:
dim MailboxWriter as new WriteMailboxToDatabase(MailboxPath, theArchive, MailApplicationOrAccount, AccountName, theExportOptions, FilemakerAppName, CurrentSession, Username)
Of course, I could make all the lower classes dependant on the new class that is handling all the options. But that would make everything dependant on the single class.
Is there a better way?
Not advocating for it, but you could use a dictionary. Using a class for your options is definitely the most sane option though. It has the type enforcement checking of using parameters, with the flexibility of a dictionary. I see no harm in making the classes dependent on the options class. You could also use multiple options classes to reduce the number of parameters, such as a DatabaseOptions class and a SessionInfo class.
Another options is to not write the constructor with so many parameters. Move some stuff into properties that can be assigned after the creation. Not sure if that would help your design in this case, but its something to consider.
And as I began, a dictionary would be an option, but you lose your type checking, plus theres no key checking either. Youd want to put constants somewhere for the keys, which at that point, just use the options class.
Thanks, Thom, an options class sounds like a better idea than a dictionary. I’ll cart that around. The dictionary sounds easier but the key checking is important.