Then it would remain to achieve the same flexibility of using interfaces with Contracts. Is it not possible to place contracts on interface definitions? Do Contracts, in practice, reply on implementation details for their operation? I suspect they must and this would be a problem.

C++ is still a powerful language, not really obsoleted by Java or C#.

The only big drawback of C++ is it’s syntax (which in turn is inherited from C), especially the use of preprocessor macros make it a PITA to process, which makes refactoring and other source code processing “potentially impossible” (read: no tool will be totally reliable).

Oh, and of course that many people never bothered to actually learn proper C++… or where to find C++ libraries (e.g. boost) that can somewhat compete with the huge class libraries of Java and C#. It’s all there, just not in one big help file as with java and C#.

In fact, Java has been hitting some of the “library problems” that have been scaring away people from C/C++. Todays java apps often come with a collection of .jar files. Replace one, and you’re likely to break something. Many people end up having a dozen copies (or different versions) of xerces on their computer, what a waste… My system has over 100 java “library” jars installed (including xerces, xalan, lucene, junit, ant, openoffice and commons) – fortunately my linux distribution handles this dependency hell just as it does for all the other languages.
All this was just “delayed” by java having a larger standard library than C++ has. And C# in turn seems to have an even larger lib. But – if you’ve ever come to develop Java for a mobile device, you’ll be aware that not all of these libraries are available on every system…

However, besides the fact that perhaps half the Java developers out there aren’t interested and capable of using it correctly, DbC has a fatal flaw. That flaw is that pre-conditions, post-conditions and invariants do not have to be correct and *complete* for the program to work correctly. So, human nature being what it is, they invariably aren’t correct. I would like to see some real DbC code and see if I couldn’t find a heap of missing conditions. These holes imply that the benefits of the approach are less than perfect.

I have seen it attempted in requirements Use Cases, by good BAs, and the results aren’t encouraging. Because it’s not the primary driver, the proper attention is not given to it being correct and complete.

So, give me the flexibility of non-final methods, and as a developer I’ll take the consequences. That is, unless you can give me a water-tight DbC scheme. If you are going to suggest unit tests as a solution, then I will use the same reason for not making methods final.

I know it’s not quite the same thing, but I’ve had to create an effective subclass of java.util.Date, for practical reasons, using delegation, and it was not pretty. A non-final Date class would have been valuable there. I suspect non-final methods would provide similar benefits.

The library working as advertised is an internal concept and entirely within the capability of the library provider to guarantee with the use of DbC. There are thousands of libraries out there that “work as advertised” without using it.

I believe that the practical benefits of being able to inject, at runtime if desired, concrete classes that satisfy an interface brings far greater benefits than anything you are suggesting.

“By being able to override anything without changing the ActiveRectord source code, you avoid this beneficial communication with the original developers.”

I think there’s a slightly different culture around this. The process at the moment (Rails is still very young) is to write a plugin that “monkey patches” Rails to do what you want if it is something you want to reuse. You can share the plugin with the world. This is how “acts_as_versioned”, “acts_as_paranoid,” and “acts_as_threaded” work at the moment.

The Rails team can incorporate the ideas into Rails or leave them as plugins if it makes more sense to let developers pick and choose. DHH says that every 37signals project uses 5-6 plugins, so he clearly likes the plugin philosophy.

I think plugin is to framework as mixin is to class. With all of the same connotations and implications raised by this interesting debate about flexibility, power, safety, ease of use, &tc.

“Bad practices you can get away with on small teams and simple projects cause problems for large teams and complex projects. ”

I would restate this as: Practices that are appropriate and cost effective on smaller teams may be inappropriate or even disastrous in larger, disconnected projects.

It seems that the real issue here is trust. It sounds like what you want is a library that will work properly no matter what a fellow programmer does. And if she ‘misuse’s the public API, or makes a mistake, you want to take 100% control of error reporting. You do not trust her to do things well. You do not trust her to debug her own problems.

If she writes her own callbacks, by passing in objects conforming to an interface or by overriding something in the library, you don’t even trust her to write her own unit tests to make sure that her own application is working properly. You want unit tests for the library that will anticipate her every move! Of course this can only be done by restricting her freedom, deprecating her from a programmer into a user.

Here’s a practical example: I am working on a Ruby project. You get truly private variables, no negotiation. But you do not get final methods. It’s better than that: you can change methods at runtime, and in fact that’s how a lot of programming works: classes from the Rails framework are actually patched in the application.

That’s what makes it possible to add version tracking to model data with a one-liner. And in my own case, I need to go one further: when one model has a reference to another model, I need to track when the reference gets out of date. I need to patch the way references work so that I can refer to a model’s ID and also its version number.

Needless to say, if the author of ActiveRecord locked his framework down, there wouldn’t be an acts_as_versioned plugin until he felt that his framework should include it. And if the author of acts_as_versioned locked his plugin down, I wouldn’t be able to created versioned_references.

However, whenever a library allows the client code to install a callback method, it’s the opposite. Then we can use a unit test to verify that the library calls the hook with the correct arguments, but for proper fault isolation, the library needs to check the hook’s postconditions when it returns. Returning from a callback method is an entry point into the library, just like a method call.

Any overridable method is potentially a callback, so this implies that the library should always check the return values of overridable methods for reasonableness. That’s enough of a burden that overridable methods probably shouldn’t be the default in a public API. Typically, the public methods should be final and the overridable methods should be protected and have default implementations that are either empty or entirely optional.

But I’m still not sure how important this is. It seems to me that there are all sorts of ways you can misuse a library that aren’t checked, such as calling a non-threadsafe class from multiple threads, or synchronizing on the wrong thing, or just hanging in the middle of a callback. Typically libraries try to check for the most common programming errors, but they don’t check for every possible programming error.

Nothing works as advertised… except in books.

“Sometimes one method in the library depends on another. If that method A is changed, method B may no longer function. Sometimes there’s more than two people involved. Developer B can change a method’s behavior in a subclass and thus break the code for developer C.”

Good automated tests (i.e. Unit Tests) should prevent this. Tests are designed from the “User of the interface” perspective. So changes in the interface should be caught very early.

“Bad practices you can get away with on small teams and simple projects cause problems for large teams and complex projects.”

Rigid code is a bad practice. Everything should be changeable in the fast-moving world of software.