How to Extend Your API in .NET

Started by
0 comments, last by ToohrVyk 15 years, 5 months ago
So I am designing an extensive class library in .NET (C#). It will reside server-side and process requests coming in through a web service. I have two goals with this lib: (1) to process data the way I want it to, and (2) to be able to generate copies of the compiled .dll file and distribute them as freeware. One problem though, is that there is one ubiquitous method in the library, called everywhere in most of the source files, that triggers functionality that I only want executing on my copy. Any freeware copies should not be able to make use of this functionality. Solutions.Commit() appears everywhere, and inside the Solutions.cs file, it does all sorts of crazy things that: (i) I want working with my web app, and (ii) don't want working when I put it up as freeware. I guess I could re-compile a "freeware" version that strips out all standalone calls to the commit() method, but that doesn't seem feasible (1000s of calls) or elegant. So I've been tinkering around with an idea, and I wanted to post it here to get anybody's feedback, and by all means, feel free to tear me a new one. Proposal: 1. Create a namespace called Extender; thus MyProject.Extender. 2. Through Solutions.cs inside MyProject.Extender and make sure to refactor all the using's and references in my code. 3. For my version, the Master (the one going into production with the web service), change nothing. For the freeware copies, erase the functionality (the definition) of the commit() method. What I'm trying to accomplish here is: (1) Prevent other users from executing the same code inside commit() as I want to have. (2) Enable users to define their own functionality, so that when commit() fires inside my DLL, it does what they want it to do. In order to facilitate this 2nd objective, I need a way to allow customizability from *outside* the library. The only way I can think of doing this is to, perhaps, refactor commit to be passed a delegate, which is defined elsewhere. But because I'm not really sure of the best way to attack this is, its difficult to conceptualize how I can achieve any of this. Any ideas here are greatly appreciated!
Advertisement
What you're trying to achieve is the textbook definition of polymorphism: you want function Commit() to behave in two (or more) possible ways.

You have three possibilities:
  • Use Object-Oriented polymorphism: right now, Commit() is a member function of a certain class. Refactor all code which uses that class to use instead an interface implemented by that class. This lets you provide a different implementation for that interface, one with a different Commit() function.

  • Use Functional polymorphism: pass the Commit() function around as a delegate everywhere.

  • Use Procedural polymorphism: replace all calls by hand [smile]

This topic is closed to new replies.

Advertisement