Peter Ritchie's MVP Blog : Pontification

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 17:55:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

Location of unit tests.

PeterRitchie — Thu, 21 Aug 2008 01:24:00 GMT

I had a short conversation at Alt.Net Canada about the location of unit tests. I personally tend towards a distinct unit test project. But, I deal with mostly commercial, off-the-shelf (COTS) projects where I simply can't ship code like that. I also don't want to wire-off the unit test via #if because I would then be shipping something different than that which was tested.

From an enterprise application point of view, this is different. I would have no problem including the unit tests within their respective project as production code

My Wishlist for C# 4

PeterRitchie — Tue, 12 Feb 2008 16:57:00 GMT

[Edit: fixed the not-ready-for-publication problems]

There seems to be more than few people blogging about what they hope C# 4 will do for them. I haven't seen one that really synchronizes with my thoughts, so I'd thought I'd post my own list.

Variance

A good story with regard to variance with generics is vital for upcoming versions of C# 4. You could argue that this should have been done in 3, but, unfortunately, that wasn't the focus. I think this really needs to be done for 4; and if Eric Lippert's blog is any indication, that may come true.

Design By Contract

Design by Contract (DbC) means programmers can define verifiable interfaces. This explicit intention information is then used by the compiler to greatly increase the compile-time checking it can do. In most cases this means no checking need be done at run-time because the compiler has verified the that condition cannot occur at run-time, increasing reliability and improving performance. There's hint of this in the framework already with the internal classes ImmutableAttribute and InvariantMethodAttribute. First-class language support for DbC would go a long way to being able to write more reliable software.

Concurrency

Various leaders in the industry (Microsoft included) are recognizing the processor speed improvements will essentially stop being vertical and continue to be horizontal (i.e. instead of increases in processor speed, increases in processors or cores will be the norm). This means that in order for applications to utilize that type of system processing throughput concurrency will become more mainstream. Microsoft has various concurrency initiatives going on (like the Parallel Framework Extensions). It's only logical that lessons learned from this project not long will make their way into the BCL and the .NET Framework but also into the respective languages (C# included, I hope). In this respect I hope that concurrency issues become first-class citizens in the library. This would include things like immutability. In the spirit of Agile development, the sooner this gets into the language the sooner it can be embraced and evolve.

Object-Oriented Programming

Much like Jon Skeet, I believe the language designers should recognize that C# is an object-oriented language first and foremost. This fact should continue to focus what, if any, aspects of other programming paradigms are added to the language. Paradigms like Aspect-Oriented Programming, Functional Programming, etc.

infoof, memberof, propertyof, eventof, methodof Operators

The information these operators require is so easy for the compiler to simply dump in the IL stream. For users to do the same thing requires that they have a string containing the name of the member in question--which can't be checked at compile time and leads to maintenance nightmares. Imagine what life would be like without the typeof operator forcing use to use code like this:

    Type type = Type.GetType("MyNamespace.MyClass");

Instead of:

    Type type = typeof(MyNamespace.MyClass);

...if I rename MyClass to UsefulClass no refactorying tool I've see will modify the "MyNamespace.MyClass" string and compilation will succeed and lead to a runtime-error.

Cleanup Some Long-standing Issues.

The above and variance could be viewed as a long-standing issues; but, I think they deserves to be called-out on they're own, they would be huge improvements. Detection of recursive properties, for example. The C# team have a backlog of a few things like this; now's the time.

Extensible Compiler

Years back my original idea for this was to have an IDE that automatically corrects mistakes. e.g. if an "; expected" error was spit out, the IDE could intercept it, correct the code, and recompile. But, this extensibility idea can be so much more than that. This sort of extensibility could introduce Aspect-Oriented Programming fundamentals or Domain-Specific Language abilities without the language really understanding the concepts at all. This extensibility would be very powerful for programmers and would give them the ability to evolve their language without being tied to the release schedule of the C# team.

Thinking Out Loud

Class-scoped aliases: Aliases in C# are a bit of a pariah, they're at global, file scope; making them not all that useful. In C++, for example, it's quite common to declare type aliases within a class declaration (usually based on a templated type). It would be nice to be able to create an instance of a type based on an alias within a class. E.g. MyType.MyAlias o = new MyType.MyAlias;

Is C++/CLI a Second Class Language with Microsoft?

PeterRitchie — Tue, 29 Jan 2008 16:03:00 GMT

The post frequency on the Visual C++ team blog is reasonably high. Some posts deal with new features that were added to VC++ 2008.

But, is Visual C++ a second-class citizen in the Visual Studio product group? Recently the Visual Studio 2008 Product Comparison was released (don't ask me why it wasn't released at the same time as the products...). In the product comparisons VC++ Express has an inordinate number of features that only it doesn't have. When you look at the Visual C++ 2008 Express Edition product sites, it seems pretty clear that it's geared towards native-only software development. Despite this the product comparison shows VC++ Express has Managed Debugging, Mixed-Mode Debugging and Compiler Support for any CPU (which details "...compile your managed application..."). But, VC++ 2008 Express is the only edition that doesn't support adding reference to WCF services ("Service Reference"), Code Snipped Manager, Code Snippets, Rename Refactoring, Text File (you can't create a plain text file with VC++ 2008 Express?), and one of two editions that doesn't include support for XML File (create a blank XML file), and SQL Server 2005 Compact Edition. As well, only VC++ 2008 doesn't include managed-only features like Object Browser, Object Relational Designer, and SQLMetal (the last two deal with .NET-only LINQ-to-SQL.

C++ has stagnated as a language for quite some time, but Visual C++ 2008 includes new language features like C++0x and TR1 that help evolve the language for the parallel future. But, despite assurances that native development is still a focus at Microsoft, there is the appearance that VC++ just isn't getting the same resources as the other editions. Makes you wonder how much longer will Microsoft keep it in the Visual Studio family...

Unified Field Theory, is it Possible?

PeterRitchie — Sun, 08 Apr 2007 15:21:00 GMT

Is Unified Field Theory possible? It sounds like it's more than elusive..

I was reading about some interesting theories that our reality may simply be a perception of several different realities. Not entirely ground breaking; but, my take on it is that if our perception of these multiple realities is a side-effect of the interaction of these realities and that each reality may not follow the same rules as the other realities, can a "unified field theory" of our perception be possible?

This may have some interesting effects in that it may affect how Moore's Law can continue through discovery of new architectures. In computer science, this will likely affect how software is written.