Rambling Comments

Implicit Interfaces

2006-01-07T09:57:58Z

ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class's implicit interface. That is, given a class that does not inherit from an interface, it's sometimes useful to be able to split the class into an implicit interface, the public operations that it provides, and treat that as if it were explicitly declared as an interface from which the class derives. This would be useful in testing as it would allow you to mock up things that are currently difficult to mock up. It's an interesting idea and it's generated a lot of talk. I'm not sure it's good though, it smacks of making things easy that are already easy if you approach the problem with enough discipline...]]> I think one of the biggest problems with this idea is, as Barry Kelly says over on Entropy Overload, classes like that often have multiple implicit interfaces and they're not always public.

I find that in C++ I tend to operate with explicit interfaces much of the time, it often works out easier in the long run to develop a class interface first, especially when developing in a TDD style. I write the test, I write the code under test, it needs to access another object to I work out the interface, implement a mock from that interface and, eventually, write tests for the object and develop the object. This is pretty much what Ian G suggests, work only through interfaces. It does require a little more discipline and it is, sometimes, overkill but it works pretty well.

Of course Martin's suggestion would make it easier to use third party code without wrapping it up in a shim of your own. Personally I think it's a good thing to get in the habit of segregating third party code and putting it behind a thin, object based firewall of your own devising. The shim/wrapper code allows you to blend the alien API into your standard ways of doing things and gives you a chance to refine the abstraction that the third party API provides. Chances are their abstractions are in terms of the problem that they solve whereas yours should be in terms of the problem that you are solving and might only use a small part of the API... What's more, if you have slipped in an interface you can test without the third party code and you can, potentially, replace the third party code with other code if required...

If you enjoyed the Petzold thing earlier...

2005-10-25T20:50:12Z

This may also be your kinda thing.

Ellen Ullman's 1998 two part series "The Dumbing-Down of Programming" from Salon archives.

Rebelling against Microsoft, "My Computer" and easy-to-use Wizards, an engineer rediscovers the joys of difficult computing.
Returning to the Source. Once knowledge disappears into code, how do we retrieve it?

Via Joey deVilla over at The Farm.

I'd forgotten how readable Ellen Ullman was (especially for techies of "a certain age"). I read a novel of her's, Close To The Machine, this time last year. Worth checking out, as is this interview with her, also in Salon.

This week is becoming one of those weeks where I'm constantly reminded about my age (it started with me discovering that my Dad can now get cheaper car insurance if he includes me on it with him!) and just how long I've been in this business...

Sacrificing precision for ease of use?

2005-09-17T10:15:50Z

I'm probably jumping the gun a little here as I can't find Herb Sutter's slides that Matt Pietrek is referring to, but... Once again I find myself asking why is it actually useful to repurpose the auto keyword in C++...

The idea seems to be that rather than this:

foo::iterator i = myList.begin();

You can do this:

// Type of 'i is inferred from the assignment
auto i = myList.begin();

]]> I really don't get what's with these "productivity" enhancements that allow people to think less whilst coding. Let's assume that I gain something whilst writing the code by using this new feature; and I'm not convinced that I would. Does someone whose job it is to maintain that code going to have the same gain? Let's consider the situation, you're looking at unfamiliar code and you come across this line:

auto i = myList.begin();

There's no indication of what myList is. There's no indication of what begin() returns. There's no indication of which version of begin() we're calling; is there a const version that returns something different to the non-const version? This code communicates less than the code that it replaces...

And, of course, this is actually quite a simplistic example. Let's say we have this function on a collection class:

const CMyObject *CMyCollection::GetObject(i) const;

So we might have a call site like this:

const CMyObject *pObj = myCollection.GetObject(i);

Which could, perhaps, become:

auto pObj = myCollection.GetObject(i);

But what we'd rather do is restrict what we use pObj for, so we decide to manipulate it via one of the interfaces that it implements instead...

const IObjBase *pObj = myCollection.GetObject(i);

How do we do that with this new fangled auto? I assume we don't?

C++ is a very expressive language; it allows you to be precise about what you want to do. What I'd like to know is what value this change has that makes up for the fact that the code is now potentially less precise and communicates considerably less? Perhaps the slides from talk will explain more... To me it just looks like the kind of thing that a lazy programmer writing a code generator would ask for...

C# v3 Extension methods, syntactic sugar for the lack of free functions?

2005-09-16T14:12:36Z

There's a lot of noise coming out of the Microsoft PDC right now. Something that interested me was the future direction of C#; you can grab the spec from here.

It seems they're adding "extension methods" which, to me, appear to be just syntactic sugar to make up for the lack of free functions...]]> In C++ you can have functions that aren't part of an object. In C no functions are part of an object. These are "free" functions. You can't have these kind of things in C# and Java because everything has to be part of an object even if the only purpose for the object's existence is to provide a home for a collection of static methods, go figure...

In C++ a recent idiom is to prefer free functions over object methods where possible. The argument is that creating non-member, non-friend, functions increases encapsulation because these functions don't need access to the object internals and therefore bundling them with the object simply reduces the encapsulation that the object provides by expanding the amount of code that has unnecessary access to the object's internals.

This means that, in modern C++, you may often see things like this:

int ToInt32(const std::string &stringRep);

which can be used like this:

const int i = ToInt32(customerNumber);

Up until now the nearest that you could get to this in C# was something like this:

public class Stuff
{
  public static int ToInt32(string stringRep);
}

which can be used like this:

int i = Stuff::ToInt32(customerNumber);

The new "extension methods" proposal means that the call above can be rendered as this:

int i = customerNumber.ToInt32();

Which, in my mind, is madness. The method is not a member of the object so why should you call it using member syntax? What value does it add to be able to do this? If you're looking to remove the crufty Stuff:: from the front of the call then why not simply allow functions to be defined at namespace scope? Then you could bring the names in with a normal using statement and use them in a way that's expected:

int i = ToInt32(customerNumber);

It's quite clear that ToInt32 comes from a namespace somewhere and isn't a member of the object in question...

So, my question to all you .Net people is why is this new syntax a good thing? I can only see scope for confusion and the eventual banning of this kind of thing in local coding standards...

Some thoughts on complexity

2004-02-29T13:57:12Z

I find that these days I prefer my complexity to be obvious. Things with hidden complexity aren't any less complex, they're just less obvious. If you make all of your complexity obvious then you know which pieces of code are complex and you can focus your attempts at simplification on the right places...

]]> Some of this comes from the testing that I've been doing; liberal use of parameterize from above means that an object that uses several services is explicitly given those services when you create it. This makes it easy to test as you can replace service providers with mocks. The complexity in the object is explicit because you can see it when you create it. It's obvious that it requires the services that it uses because you have to provide them at creation time. Some of it from a general distrust of 'dumbing down'; I've always thought that dumbing down is for the dumb...

The result of obvious complexity is that you need to make decisions before you can use it. You need to think. Taking The Server Framework as an example; the server requires that you provide a object that implements the IIOPool interface, a socket allocator and a buffer allocator. At present the socket and buffer allocators are concrete objects, but they would have been interfaces if the code had been developed test first and they will probably become interfaces at some point in time. The server looks complex. Some might say it's harder to use because the complexity is obvious and that it would be better if the designer of the object made these decisions for the user. I'd prefer the user to learn a little more about the code they're using and make the decisions themselves. It makes my job, as a designer, easier, I don't have to know more than all my potential users, I can be stupid and it doesn't matter because the code is flexible and they can configure it how they want to. The user needs to take a little more time, perhaps, to understand what's going on; but once they do, they can make decisions that are appropriate for them.

I find that the complexity rises up the layers of code to the point where the decision can be made and at that point a new class is created that contains those decisions. Sometimes this decision point is at the top of the code, in main; sometimes, often, it's lower down. My point, I think, is that I like code where the decision point is under my control. For me this reduces risk. If I decide to use code where the decision point is inside the library or framework then I am tying my success to the fact that the library or framework designer knew better than me and made the right decisions. I don't mind the designer providing me with sensible defaults, I do mind when some things are made impossible.

I guess this is related to Joel's Law of Leaky Abstractions. I'm accepting that my abstractions can never be "perfect" for users that I don't know who have uses that I haven't thought of. In deference to them, I prefer to build in some flexibility. Providing flexibility means not making decisions that can't be changed and making the complexity obvious and so allowing your users to understand the complexity and make appropriate decisions.