How to do Dynamic Proxies in C#

Background: A dynamic proxy dynamically generates a class at runtime that conforms to a particular interface, proxying all invocations to a single ‘generic’ method.

Earlier, Stellsmi asked if it’s possible to do this in .NET (it’s a standard part of Java). Seeing as it’s the second time I’ve talked about it in as many days, I reckon it’s worth blogging…

As far as I know, there are two ways to do this:

* Using the magical RealProxy class that monkeys with the context (whatever that means). This requires that the object that is being proxied must extend ContextBound.
* Using Reflection.Emit to generate a new class at runtime that overrides/implements the necessary methods and dispatches invocations to a generic handler. This can implement an interface or override any virtual method.

The first approach is pretty trivial, but it locks you into the fact that you can only proxy objects that extend ContextBound. Not ideal as this pulls a lot of stuff into your class you don’t necessarily need and prevents you from inheriting something else.

The second approach is more suitable, less intrusive, but not pretty to write as it involves writing low-level IL op-codes. However, I did this already in NMock and at GeekNight, Steve and Jon lovingly decoupled the ClassGenerator from the core of NMock, so you can create generic dynamic proxies. So now it’s easy to create a proxy.

h3. Example

Here’s an interface you want to create a dynamic proxy for:

interface IFoo {
string DoStuff(int n);
}

Note:

* You can use one invocation handler to handle all method calls in the interface. The example above only has one method for clarity.
* This doesn’t have to be an interface. It could be a class, so long as the methods you want handle are all marked virtual (sigh).
* You can do the same thing for properties as well as methods.

To create the proxy, you need to create an implementation of IInvocationHandler. This is called any time a method is invoked on the proxy.

class MyHandler : IInvocationHandler {
public object Invoke(string methodName, param object[] args) {
return "hello from " + methodName;
}
}

Notes:

* The name of the method being called and parameters passed in are passed to this handler.
* Whatever is returned by the Invoke() method is returned by the proxy.
* If the method is of type void, just return null.

Finally, you need to generate the proxy itself so you can actually use the damn thing:

ClassGenerator generator = new ClassGenerator(
typeof(Foo), new MyHandler()  );
IFoo fooProxy = (IFoo)generator.Generate();

string result = fooProxy.DoStuff(2); // returns "hello from DoStuff"

Ermm and that’s it! Use your dynamic proxy like it’s a real class.

ClassGenerator is part of the NMock library. Use it for AOP style interceptors, decorators, stubbing, mocking :), whatever.

Brain rumblings… Hmm… maybe that should be a delegate instead… maybe I should revisit some stuff…

Making JUnit friendlier to AgileDox

Here’s a little trick to make JUnit display your test results in a similar way to AgileDox.

Override TestCase.getName() in your unit test…

public String getName() {
return super.getName().substring(4).replaceAll("([A-Z])", " $1").toLowerCase();
}

… and your test runner results are transformed from this …

… to this …

To make this easier, stick it in an abstract TestCase and inherit from that instead.

Inversion of Control and Dependency Injector Pattern

Martin Fowler has pubished a new article:

bq. In the Java community there’s been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig into how this pattern works, give it the more specific name of “Dependency Injector”, and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.

Read more

What’s a YAUL? Or a YAUC?

Hani has a very valid post about util libraries.

Libraries that just have a bunch of non focussed utils in them, rarely provide a benefit to anyone other than the original authors.

When developers are looking into using a third party library, it is for a specific reason. A library that has a specific focus may meet this requirement, whereas an all-purpose util library rarely will (and even if it does, it is unlikely that it will be found).

Much of the code within the library may serve little purpose outside the context of the application it was originally built for, but not necessarily all.

By identifying the code within that has defined focus, you can extract that out and provide a library with a specific purpose.

Example

Whilst developing many parts of OpenSymphony (and our own bespoke applications that use OpenSymphony), we noticed there were many odd little methods that we found useful, which lead to the conclusion that other people would also find them useful. We slapped them together into a util library and OSCore was born.

This library lacked a clear responsiblity and in the end became a dumping ground for code that didn’t seem to belong elsewhere. As a consequence, it wasn’t successful. No one is going to choose to use a library that does this, that, a bit of this and has that really useful method there.

Eventually this was learned and the one part of the library that had a clearly defined use (PropertySet) was split out into its own project. Today, PropertySet is a well used library, whereas the rest of OSCore has faded into the background.

Incidently, this is a lesson we learned early on in OpenSymphony and the result has been many quality components since, many of which I rely on today.

YAUCs

As well as libraries, this also applies to individual classes. A class named CheeseUtil express very little about the focus of the class other than it’s got something to do with cheese. As a result util classes often grow fairly big and lack clear design (in fact, they often end up as a bunch of public static methods).

In this case a util class can be refactored into many smaller classes which can each flourish on their own, with their own design.

YAUC Example

In OSCore there’s a class called XMLUtils.

From the JavaDoc:

XMLUtils is a bunch of quick access utility methods to common XML operations.

These include:

* Parsing XML stream into org.w3c.dom.Document.
* Creating blank Documents.
* Serializing (pretty-printing) Document back to XML stream.
* Extracting nodes using X-Path expressions.
* Cloning nodes.
* Performing XSL transformations.

Authors: Joe Walnes, Hani Suleiman :)

Unless someone had specifically looked at the JavaDoc or methods of every single class in the system, there would be little chance of knowing that.

Breaking this class up into many smaller classes, errm, objects such as XMLParserFacade, XMLPrettyPrinter, NodeCloner, XPathEvaluator and XSLTransformere, expresses the intent clearer and is much more likely to be found.

(Hani and I have since learned from these mistakes).

h4. Conclusion

Small and clearly defined responsibilities for libraries and individual classes results in improved reuse as they have an increased chance of meeting part of a developer’s requirement.

When simplicity backfires

I put a lot of effort into refactoring a larger, more complicated library into the lean and simple Squiggle you see today.

Annoyingly…

bq. Freshmeat tries to avoid listing projects which fall below a certain level of size and/or complexity, and yours is unfortunately a bit too simple for our application index. Your contribution has been respectfully declined.

Easily build complicated SELECT statements with Squiggle

After serving me loyally for four years, I’ve finally got around to open-sourcing Squiggle – a small Java library for dynamically building complicated SQL SELECT statements.

Sometimes (not often these days) you just need to get your hands dirty and write a beastly SELECT statement. Maybe a persistence layer is deemed overkill for your application, or maybe a persistence layer is struggling with the type of query you want to do. There are times when writing some SQL is the right thing to do.

Here’s the blurb from the website:


Squiggle does one thing and only one thing. It generates SELECT statements based on criteria you give it. It’s sweet spot is for applications that need to build up complicated queries with criteria that changes at runtime. Ordinarily it can be quite painful to figure out how to build this string. Squiggle takes much of this pain away.

The code for Squiggle is intentionally clean and simple. Rather than provide support for every thing you could ever do with SQL, it provides support for the most common situations and allows you to easily modify the source to suit your needs.

Features

* Concise and intuitive API.
* Simple code, so easy to customize.
* No dependencies on classes outside of JDK1.2.
* Small, lightweight, fast.
* Generates clean SQL designed that is very human readable.
* Supports joins and sub-selects.

Here’s a very simple example:

Table people = new Table("people");

SelectQuery select = new SelectQuery(people);

select.addColumn(people, "firstname");
select.addColumn(people, "lastname");

select.addOrder(people, "age", Order.DECENDING);

System.out.println(select);

Which produces:

SELECT
people.firstname ,
people.lastname
FROM
people
ORDER BY
people.age DESC

Go check out the website and two minute tutorial.

Running Groovy natively without the JVM

Two days ago I was hacking away at some Ruby scripts and thought it would be nice if I could write them in Groovy (not necessarily useful, just nice).

Of course, for small scripts that honour the UNIX philosophy, that would be a terrible idea. These scripts should start instantly and have minimal overheads.

What changes would be needed to allow Groovy to compete with languages like Perl, Python, TCL, Ruby or plain old shell scripts in this space?

* Better performance / reduced overheads (cpu, memory, start-up time).
* Simple install (src tarball, RPM, dpkg, windows installer, OS-X whatever).
* No JVM required.
* Ability to use Groovy to access less Javaish libraries (POSIXy style stuff, MFC, .NET).
* Ability to use Groovy (and Java) objects from other languages (C, C++, Perl, Python, Ruby, .NET, etc)

As an experiment, I’ve created a subproject of Groovy (groovy-native) that aims to address these issues.

Take a peek at where I’m going with this.

So far:

* Created a stripped down native runtime library (libgroovy.so).
* Compiled a .groovy file to a native executable (linked with libgroovy).
* Created a native C++ app that calls interops with Groovy objects.

Java Open Source Programming book biled

Well I knew eventually the book would be biled.

While I usually find negative feedback very helpful (thanks Werner!), I feel that Hani’s review has unfortunately missed the point of the book.

The book is based around the theme of improving development productivity and the quality of real world systems through simplifying code. Whereas many other books on the shelves at the moment are ‘bibles’ that provide a comprehensive in-depth guide to specific technologies, this book tries to do something different by illustrating how using some simple tools and design techniques you can stay on top of development. Admittedly, the title of the book doesn’t convey this – I hope that really isn’t a reason to read the book.

The simplicity expressed in the JUnit and mock objects chapters was exactly what we were trying to get across to the reader. Rather than providing a brute-force approach to testing complicated applications by using tools equally as complicated, we advocate simplifying the design of applications.

Through using techniques such as test driven development (though not exclusively), you are driven towards this simpler design. Rather than show how you can use mock objects to test complicated things like environment, resources and complicated dependencies, we show how you can alter the design of your code so these complexities are encapsulated behind simpler abstractions. The examples used in many of the chapters are not much simpler than those used in my real applications at work – and I don’t write pet stores for a living ;).

There are also books that go into the theory behind simpler design, we try and make it more concrete by showing how you can make these kind of abstractions with technologies that are common in the Java development community. We often promote the use of one technology over the other (for example WebWork over Struts or Hibernate over CMP) because these are more geared towards simplicity and abstraction. In these cases we often summarise the key differences between these technologies. That’s not to say that this book is useless to you if you are not using these technologies as the simplicity we illustrate is beneficial in many kinds of application development.

Even if you are familiar with (or choose not to use) the technologies explained in first half of this book, the second half really captures what we are trying to get across. It illustrates by example how the technologies and techniques come together in many small steps, creating a system that can evolve, scale and has a high quality of design.

One of the most challenging tasks of writing a book is putting yourself in the mind of the reader audience. Some content may be obvious to some people. Some people may find none of it useful. Our aim is for most people to find most of it useful, which as Hani has made clear, unfortunately means most people find some of it completely useless.

If Hani’s review has put you off from reading the book, please take time to look at some other reviews (positive and negative) and remember that Hani’s view more-often-than-not skips over the positive aspects of something he is critiquing.

XStream 0.2 released

See this.

Java Open Source Programming book reviewed on TheServerSide

Dion Almaer has reviewed our book:

* Full review
* Discuss the review

I’m glad he picked up on many of the points we tried to emphasise to make the book stand out from the crowd.