Ted Neward highlights a tendentious piece of advice for people using C++/Java/C#:

In his excellent podcast entitled "Emergent Design: The Evolutionary Nature of Software Development," Scott Bain of Net Objectives nevertheless makes a strong case against the routine use of public constructors.  The problem, notes Scott, is that the use of a public constructor ties the calling code to the implementation of Foo as a concrete class.  But suppose that you later discover that there need to be many subtypes of Foo, and Foo should therefore be an abstract class instead of a concrete class--what then?  You've got a big problem, that's what; a lot of client code that has been making use of Foo's public constructor suddenly becomes invalid.

Here's a thought: Try the simplest thing that could possibly work, and go back and refactor it later if you actually need to.

Then again, for people using those languages, maybe the up front investment in "maybe I'll need all of this later" is necessary - because the language and tools are so hard to work with. If you end up there, maybe you should question your tools.

He does note later on that Smalltalk and Ruby do this much more cleanly:

Meanwhile, other languages choose to view new as one of those nasty static methods Gilad dislikes so much, Ruby and Smalltalk being two of them. That is to say, construction now basically calls into a static method on a class, which has the nice effect of keeping the number of "special" parts of the language to a minimum (since now "new" is just a method, not a keyword), makes it easier to have different-yet-similar names to represent slightly different concepts ("create" vs "new" vs "fetch" vs "allocate", and so on) sitting side by side

The Gilad mention is to this, and I'm not at all convinced that Smalltalk's #new qualifies.

Technorati Tags: smalltalk, ruby, C#, Java