In my last post I talked about serializing Enumeration Classes for use with WCF. In this post I’m gonna show you how to add a feature that real enums have but enumeration classes don’t. Yet!
Enums can be decorated with the FlagsAttribute. This allows you to combine single enum values using the ‘|’ operator. A sample from the System.Reflection namespace are BindingFlags.
To find out wether a single value is part of such a combination you use the ‘&’ operator.
The result will be BindingFlags.Public.
To make our lives easier when implementing flags based on enumeration classes we will also use a generic helper class Or<T>.
Now we are armed to build a custom flags class with minimal effort.
Admittedly this is much more code than you would have to write for simple flags based on an enum. But the additional power of enumeration classes can also be found in the flags classes. Think of a user selecting from a set of predefined filter criteria. As long as Microsoft does not make expressions serializable you have no way of dynamically building the desired filter on the client side and send it to the server for evaluation other than directly accessing your database (be it SQL or NoSQL) and let some LINQ provider do the translation from expression to native query for you. With flags classes you can combine an abstraction of your filters on the client side, send the flags and let WCF do the reconstruction of the filters on the server side.
As a “tame” example of such a static object think of the File class. Now imagine you have a component that uses File.Exists(). How do you test that code? Do you really want to create a file whenever you try to run a test of your component?
Lets look at a sample to show how you can still test that code.
In order to simulate the situation where the file exists you would have to create said file. That’s not what unit tests are for. They should be almost effortless to write. Wrestling with the file systen in a unit test scenario is definitely not effortless.
But that’s not the whole story. We need a way to simulate the result of FileWrapper.Exists() or we would just add code but won’t gain anything. To do that we lend ourselves the solution Microsoft used for HttpContext. We introduce a base class with all virtual properties and methods.
Now we change our component to use some instance of FileBase instead of the static File class.
We can use Moq or some hand-crafted test double that implements FileBase to simulate the existance or non-existance of said file very easily.
To make things a bit nastier imagine that MyComponent is used throughout a large legacy codebase. You just changed the signature of it’s constructor. Now you would have to change all calls to that constructor immediately or the system will be broken. That’s not an option.
But if we add a constructor overload that delegates to the constructor we just created and uses the default implementation for FileBase we can leave all calls to the default constructor in place but still have the improved testability of the constructor that follows the Dependency Injection Pattern.
They are called Guards or Validators. It’s their duty to keep your business logic safe. Invalid input values are rejected by throwing exceptions at the caller to notify him about his wrong-doing. Guards enforce the contracts of your API. If you fail to get past them, it’s your problem, not that of the author of said logic.
But do you really want to see them in the StackTrace of each exception they throw? They are not the reason an exception occured. They just contain the location where the exception originated. But the cause for the exception is the call to a method using the wrong parameter values.
I first saw that code in a colleague’s project. But it is also documented on StackOverflow.
Create a custom Exception that will be thrown by your Guard class. Override the StackTrace property and remove all lines that are related to that Guard class before you return the trace.
With this little trick your Guards won’t show up in StackTraces. But you don’t want to step through them whenever you debug a method they guard either. After all they are not part of the logic of the method they just enforce the method’s invariants.
You might have noticed the DebuggerStepThroughAttribute on the AssertNotNull method. This attribute instructs the Visual Studio debugger to ignore this method completely.
It’s easy. It’s neat. It helps your developers and administrators to focus on the actual source of the problem instead of distracting them with the noise of your validation code.
“Don’t give me what I asked for! Give me what I want!” – How often did you shout that sentence at your computer during the last week?
Sometimes you misspell a word or a name. Sometimes you don’t know for sure how it is spelled but have a vague idea.
Google gives you suggestions when it thinks it knows what you really wanted as does RavenDB and many others.
The output of these algorithms varies from 4-character strings to values in the range of [0..1] to the number of differences between the compared strings. If you want to make the different algorithms interchangeable in your application you would need to convert these heterogeneous values to a specific numerical range. I made some attempts to that as well but did not put too much effort into it.
It was an interesting experiment!
Get the source code for the above algorithms here (project TecX.StringSimilarity and the test suite that puts them to use in TecX.StringSimilarity.Test).