Contract Naming

Jul 16, 2009 at 1:56 PM

I'm making a decision that I wanted to throw out for comment.

I have a series of contracts that do the same thing. The exporting classes will all just have an Output method. I can think of a few ways to handle this...

  • - Use a string contract. I dislike explicit string contracts except when I am picking up a primitive type with a specific purpose
  • - Use a single IOutput interface contract and metadata string to differentiate which class should be used
  • - Have separate empty contracts for each purpose and have them all inherit from the IOutput interface

I am leaning to the third approach but wanted to see what other folks thought. I want to make it very easy for people to create new purposes, and want to avoid strings as much as possible. People adding new purposes will already be recompiling the app I expect, although any approach but explicit strings may require them to recompile an assembly they otherwise would not need.

These purposes are very unique, and the fact they all just use the same single method does not seem important. I perceive them as more than variations on a theme and the third approach provides Intellisense

Thoughts?

Jul 16, 2009 at 5:18 PM

Hi Kathleen,

I’d suggest that you stick to what would feel right in a non-MEF OOA/D situation.

E.g. in an imperatively composed application:

· If you’d use something like IDictionary<string, IOutput> to select and interact with these objects polymorphically, the #2 would make the most sense to me

· If you’d treat the output objects as completely separate concepts using variables/members with concrete types or within independent execution paths I’d go for #3

Sounds as though you’ve chosen #3 for similar reasons.

It is hard to say much without a deep understanding of your application J. Generally the “what would I do if I wasn’t using MEF?” rule of thumb seems to work. All new territory to explore though!

HTH,

Nick

From: kathleenDollard [mailto:notifications@codeplex.com]
Sent: Thursday, July 16, 2009 6:56 AM
To: Nicholas Blumhardt
Subject: Contract Naming [MEF:62633]

From: kathleenDollard

I'm making a decision that I wanted to throw out for comment.

I have a series of contracts that do the same thing. The exporting classes will all just have an Output method. I can think of a few ways to handle this...

  • - Use a string contract. I dislike explicit string contracts except when I am picking up a primitive type with a specific purpose
  • - Use a single IOutput interface contract and metadata string to differentiate which class should be used
  • - Have separate empty contracts for each purpose and have them all inherit from the IOutput interface

I am leaning to the third approach but wanted to see what other folks thought. I want to make it very easy for people to create new purposes, and want to avoid strings as much as possible. People adding new purposes will already be recompiling the app I expect, although any approach but explicit strings may require them to recompile an assembly they otherwise would not need.

These purposes are very unique, and the fact they all just use the same single method does not seem important. I perceive them as more than variations on a theme and the third approach provides Intellisense

Thoughts?

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com