Tuesday, February 28, 2006
Creational dependencies and attributes
True extensibility requires a mechanism to handle creational dependencies. Factories are a common design construct to handle those dependencies, but often they don't really remove dependencies: they just concentrate them in a single class.
In C++, thanks to the automatic creation of static objects, it is possible to have self-creating prototypes (or single-product factories), automatically registering themselves in a repository. This is a nice form of Product Trader, a pattern that is often mistaken for a "simple" factory.
In C#, static objects aren't created unless needed, so this approach can't be used. That means we have to resort to other language-specific constructs to have truly extensible software.
Reflection is probably the first idea coming to mind. In C#, creating an object having the class name (as a string) is trivial. However, we probably don't want the product (in the Product Trader terminology) name to be the class name. Therefore, some kind of indirection is needed. This indirection is often realized through a configuration file, which is a good solution in many cases, especially when products will be provided as external plug-ins.
In simpler cases, however, an external file is undesirable. It would be better to simply decorate methods (using .NET attributes) as being factories. A general-purpose, reusable product trader could then discover all the decorated method through reflection, and build a map of product factories. This could be done transparently, the first time the product trader is asked for a product.
I've written code for this reusable, attribute-based product trader under .NET 1.1, and it works like a snap. Now I'm considering building a better version in .NET 2, using generics to increase type safety. Curiously enough, it's not that trivial :-). Anyway, when I'll finish I'll probably write a short paper about it, and post the code here.
Sunday, February 26, 2006
Vanity Search
However, Google volunteered :-)) to do some work for me when they created Google Scholar to search scholarly papers, and Google Book Search to search inside books (although not so many books are indexed [yet]). So, here is the result of my little vanity search on those two services. Not quite extensive as a real backlinks page would be, but not so bad :-).
While speaking about vanity :-))), here is an IBM Patent referencing one of my articles (you have to scroll down to "Other References" to see it).
Friday, February 24, 2006
C++ Standards Committee Papers
Tuesday, February 14, 2006
Estimation and Probability Density
Monday, February 13, 2006
Corso Software Project Management
Ho finalmente messo online il programma del mio corso Software Project Management. Come si evince dal nome :-), il corso e' dedicato al PM di progetti software, che non sono progetti come gli altri.Oltre al programma, trovate alcuni cenni al corso in un mio post di ottobre, ed alcuni cenni (ed altri riferimenti) ad argomenti comunque correlati in un post di novembre.
Labels: announce, project management, teaching
Sunday, February 12, 2006
Quotation of the day
Here are a few more quotes from Tony (who, for the few out there who don't know him, invented quicksort among other things).
Walking on sunshine...
Sunday, February 05, 2006
Type Inference in C#: No Trail Arguments Deduction
class TestAccording to the C# Version 2.0 Specification, "The presence of type inference allows a more convenient syntax to be used for calling a generic method, and allows the programmer to avoid specifying redundant type information". All so true. Unfortunately, they didn't look close enough to what C++ can do, that is, trail argument deduction.
{
private static void f< T >( T p ) { }
public static void Main()
{
// explicit type argument
f< int >( 3 ) ;
// type inference
f( 3 ) ;
}
}
This is legal C++ :
template< class T1, class T2 > void f( T2 p2 )but this is not legal C# :
{
}
int main()
{
f< double >( 3 ) ; // calls f< double, int >( 3 )
}
class TestWhy would you want trail argument deduction? For the same reasons you want type inference: to get a more convenient syntax, and to avoid specifying redundant type information. (Of course, in real cases, f would make use of type T1 inside its body; I could definitely use something like that for my GUI rules library [see my post "C#: In search of language"]).
{
private static void f< T1, T2 >( T2 p ) { }
public static void Main()
{
f< double, int >( 3 ) ; // works
f< double >( 3 ) ; // error
}
}
Overall my experience with C# is mixed. There is some good stuff in it. But as soon as you try to do something slightly more advanced, you're hitting a wall. It's so disappointing. Gotta do something about it :-)).
Friday, February 03, 2006
Work Smarter, Not Harder
However, that was a good advice indeed. In the past two days I've been consulting on a data replication - sinchronization - fusion problem. There are a number of issues involved, including a legacy system with severe data quality problems (data is not really in a format that makes this kind of stuff easy, and changing structures is a difficult, costly, error-prone activity). Currently, deployment is quirky to say the least.
I contributed with a few good ideas, changing long, manual, error-prone procedures into short, automatic, safe procedures. I also brought back attention to the data quality issue, which was no longer consided part of the problem, trying to draw a roadmap to gradually move outside the quagmire. At the end, we had a short-to-long term stratey, consisting of six steps, each one bringing some improvement at a reasonable cost (and risk). I'm confident we will take the first 3 steps. Steps 4 to 6 may or may not see the light, depending on future business & technological issues (and on human factors as well :-).
All this required thinking outside the box. Weinberg, in his "precision listening" concept, told us to watch out for absolutes, like "this can't be done". Sure it can. We just need to find a way :-). Too often, we don't see a way because we're trapped by linear thinking. Still, we can spare ourselves a lot of hard work by finding creative solutions, requiring little manual coding. Actually, I don't believe in hard-work in programming. If we're working too hard (I mean long hours of pure coding, bug fixing, patching around fragile systems, etc) often we're not looking hard enough (or haven't been looking hard enough :-) for a better way to do the job. [Or we overpromised, either by lack of technical or managerial skills, but even there, often we've not been looking hard enough for a better way to get the job :-)]
