Thursday, August 31, 2006
Funny quotes
Saturday, August 26, 2006
My paper on IEEE Software
Monday, August 21, 2006
Structural Conformance in C#
Another model of conformance is called structural conformance. Simply stated, a class is structurally conforming to an interface if it implements all the method declared in the interface, without any need to explicitly naming the interface (a more comprehensive definition of type conformance can be found here). So, given this C# code:
interface IfcC is structurally conforming to Ifc, but not name-conforming.
{
void f( int x ) ;
}
class C
{
public void f( int x ) { ... }
}
Structural conformance is not without dangers: a class may be accidentally conforming to an interface (for a slightly related problem: C++ templates use structural conformance to an implicit interface, that makes things more powerful and even more dangerous).
Still, structural conformance is extremely useful during maintenance and integration. Being able to retrofit a class under an interface, without any modification to the class, can be a real boon in many real-world situations (unavailability of source code being the most significant).
Lacking structural conformance, we usually end up with some kind of Adapter. The Adapter can also rename functions, and in some cases can add some [little] adaptation logic between calls. The trouble with the adapter is that we have to write one :-).
In the last few days I've spent some hours thinking about a library for Structural Conformance in C# 2.0 / 3.0 (aka Linq). It has been pretty easy to come up with a working solution that needs a little polishing. Right now, in the case above, I can write (in C# 3, using extension methods)
C obj = new C() ;That gives a fast custom adapter between the C and Ifc. Fast means that there is no slow Invoke involved: the performance would be identical to an hand-crafted adapter.
Ifc i = obj.As< Ifc >() ;
My library can also handle renaming, although the syntax, right now, is somewhat lacking:
class C2Renaming calls can be cascaded to rename more than one method. The syntax here is for C# 3.0, in C# 2.0 the call needs to be more explicit, like
{
public void g( int x ) { ... }
}
C2 obj2 = new C2() ;
Ifc i2 = obj2.Renaming( "f", "g" ).As< Ifc >() ;
C obj = new C() ;
Ifc i = StructuralAdapter< Ifc >.Wrap( obj ) ;
C2 obj2 = new C2() ;
Ifc i2 = StructuralAdapter< Ifc >.Renaming( "f", "g" ).Wrap( obj ) ;
Suggestions for improving the syntax are welcome.
I'm thinking about extending the concept of structural conformance to extension methods as well, but that will have to wait for a while. Right now, once I made my mind on the syntax, I'll have a little clean-up to do and then I'll make the library freely available here. Later on, I may write a short paper describing all this stuff with some more depth.
Caveat emptor: while true structural conformance is a compile-time, statically typed concept, this is a run-time, dynamically typed concept, so the Wrap / As functions can throw an exception if the class is not really conforming. On the other hand, previous works (mostly by Vincent Russo) to add structural conformance to Java and C++ in a type-safe way required changes to the respective compilers. As I consider this concept useful mostly in specific software integration / evolution situations, a dynamically typed solution that can be implemented as a library is not that bad :-).
Tuesday, August 08, 2006
More on Quantitative Design Methods
The model is quite simple, meaning:
- the input parameters can be measured on an early prototype or estimated easily
- the math involved is simple enough to be implemented in Excel :-)
Still, the model accounts for the non-linearity of loading. More specifically, it acknowledges the fact that response time degrades when the server is concurrently serving several requests. So, although very simple, the model can give a first-cut approximation of response time, useful for early server sizing.
The model is too simple to account for the dynamics of any specific server / container. For instance, there is no way to account for massive swapping due to large memory footprint when too many requests are served, or for the dynamics of garbage collection, and so on. Still, it's much better than just throwing a few number in a linear model, or just implementing the system without any attention to performance issues.
Sunday, August 06, 2006
BetterEstimate paper online
There you'll find the rationale behind the BetterEstimate tool, an empirical validation of the approach, etc. Comments are welcome!
