D Melodic Minor Accidental : OO Design 101

"Find All References" Design, regarding interface members

TheoY — Thu, 07 Jul 2005 01:42:00 GMT

One of the things that I've been working on to help finish Whidbey, are the new refactoring features. However, I've recently found myself questioning the design for "Find All References", in regards to its handling of interface members. I discovered this behavior while writing a toy project in C#, but the following example illustrates it better, in my opinion. Imagine you're writing a generalized library - and provide two different interfaces, IResource and IStream. Both of them have the notion of a Close() method (for simplicity sake, I'll put the interfaces in separate files, which will help make it easier to see the design confusion):

namespace Library {

public interface IResource {

void Close();

}

namespace Library {

public interface IStream {

void Close();

}

Simple enough, right? The conundrum arises when you have an object that implements both interfaces, and uses the the same member to implement them, such as the following:

using Library;

class NetworkSocket : IResource, IStream {

public void Close() {

}

What struck me as awkward, is that if you then do "Find All References", on IStream.Close(), you'll get the following results:

(Definition) NetworkSocket.cs - (5,17): public void Close() {
(Definition) IResource.cs - (5, 14): void Close();
(Definition) IStream.cs - (5, 14): void Close();

Thus, intellisense reports that IStream.Close() is defined in all of those three places. However, why is IResource.Close() in this list? Some IDE-team members argue that the design was that we would return the transitive closure of all of the methods that are captured during this find process. I, however, argue that this is definitely unintuitive. This gets worse too, for example, introduce the following:

using Library;

class OtherResource : IResource {

public void Close() {

}

using Library;

class OtherStream : IStream {

public void Close() {

}

using Library;

class StreamReader {

public StreamReader(OtherStream stream) {

// ...read the stream ...

stream.Close();

}

Now, invoke "Find All References" on IResource.Close(). You'll get the following results:

(Definition) NetworkSocket.cs - (5,17): public void Close() {
(Definition) OtherResource.cs - (5,17): public void Close() {
(Definition) OtherStream.cs - (5,17): public void Close() {
(Reference) StreamReader.cs - (6, 16) : stream.Close();
(Definition) IResource.cs - (5, 14): void Close();
(Definition) IStream.cs - (5, 14): void Close();

IStream.Close() is on the list (which is the reverse case of the previous "strange" element), but what really makes me think this is wrong, is that StreamReader's use of OtherStream is there. OtherStream doesn't even implement IResource, so it's impossible for OtherStream.Close() to be related to IResource.Close(). In that context, you *know* you're not dealing with an IResource, however, it's still a reference <shrug>. This gets worse as you have more types that implement IResource or IStream, because whenever you do Find All References on Close(), you get even more unexpected results to wade through.

So, you wonder, is there any method behind the madness? It's all about Rename refactoring. If you rename IStream.Close() to something else, you better rename IResource.Close() to the same thing, otherwise the NetworkSocket class will suddenly no longer implement all the members of IResource. I think that's a valid concern, but IMHO, if you're sharing implementations on the same member, and then you rename one of the interfaces's declaration of that member, then I would expect a compiler error to be introduced, saying that you can no longer implement both interfaces with the same member now. Just because one developer happens to implement my interface, and someone else's interface, doesn't mean that if someone else renames their interface member that I too should be renamed.

So, mine is obviously a directed perspective, but how do the rest of you out there feel about this?

More Singleton

TheoY — Fri, 21 May 2004 10:29:00 GMT

Ok, so I lied: I'm not moving on to unions quite yet. Cyrus brought up a great point on the last post about .NET serialization, as well as the lack of thread safety in my third example. Due to the shared nature of singletons, I have to agree that thread-safety is an important enough requirement to mandate an expansion of the singleton story...

In addition, Andrew provided a great link about some other thoughts on implementing singletons in .NET.

http://www.yoda.arachsys.com/csharp/singleton.html

It introduces a neat way to resolve the thread safety by relying on the lazy loading of types in .NET. Although the article from arachsys.com doesn't mention serialization, if you read the MSDN reference on System.Runtime.Serialization.SerializationInfo, its example includes a way to control reinstantiation during deserialization in order to obtain the shared instance instead of the default serialization behavior of invoking a constructor. In doing so, you have to create a type that proxies for you during serialization -- but there's no reason why it shouldn't be the same nested type used for delay loading of the lazy-shared instance. Thus, whip in some explicit interface implementations (comment if you really want me to cover this topic), and voila!, you get the following:

[Serializable]

sealed class Foo : ISerializable {

// change the default constructor to private

private Foo() { }

public static Foo Only {

get { return SerializationProxy.sharedOnly; }

}

public object DoFunctionality();

[Serializable]

private class SerializationProxy : IObjectReference {

internal static readonly Foo sharedOnly = new Foo();

object IObjectReference.GetRealObject(StreamingContext context) {

// When deserializing this object, return a reference to

// Foo's singleton object instead.

return sharedOnly;

}

[SecurityPermission(SecurityAction.Demand,SerializationFormatter=true)]

void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) {

info.SetType(typeof(Foo.SerializationProxy));

}

The example differs from both the MSDN example and the arachsys.com article, but I'm pretty convinced it's the right thing to do. Creating a new type for serialization proxying is pretty much necessary unless you want to change the constructor semantics for the singleton type itself. Consider the following:

Assume type Foo is its own serialization proxy. During deserialization, the proxy instance of Foo is deserialized by default serialization means -- which involves invoking some constructor (either compiler provided default constructor, or user-coded). Thus you lose the invariant that any instance constructor is only invoked once, since some instance constructor has to be invoked at every proxy deserialization before GetRealObject() is invoked on the proxy.

It seems better to “de-singleton” the proxy type and hide it away, and a private nested type comes natural to my mind. Since it's nested, it allows us to also follow the arachsys.com and change the loading of the actual singleton instance to a form of "lazy loading", without ever having to introduce a synchronization keyword (e.g. "lock") or use the synchronization API. Albeit, the code doesn't really reflect in its structure that it's particularly both threadsafe and lazy-loading.

So, why do we really have to worry about serialization? Mostly because any of these implementations only guarantee one instance per AppDomain, which is somewhat like a process-like abstraction for .NET, except you can have more than one AppDomain per process. Each AppDomain has its own copies of static data though, so you can shield the effects on one against the other. Sometimes this is what you want to do (say you're running some untrusted code). However, this also prevents them from really sharing singleton instances. Also, when you have two .NET programs communicating across different processes (either concurrently, or different invocations using saved state), or on different computers, serialization becomes key.

I still probably use, in practice, the first or second simplistic singleton implementation -- with the addition of serialization support if necessary... but covering this topic has definitely brought new light to my own design toolbox -- I'll probably opt for this nested-lazy-serializable implementation a lot more in the future.

Singleton Pattern

TheoY — Fri, 21 May 2004 06:50:00 GMT

In the beginning, there was...

the singleton.

Everything's got to start somewhere. Just like there's only one object type to “rule them all”, the singleton represents cases where there's only one.

A pair of examples are the TextWriter instances that represents Standard Out and Standard Error. You only need one instance for each of those, for your entire program. It makes sense for all the code in your program, all the threads, all of ___(insert something here)_____, to share. Since there's only one for the entire process, then you might as well represent it that way in your library or codebase.

Like the proverbial skinning of the cat, there are a bunch of ways to do this. Here's a common one, say our type is Foo.

class Foo {

// change the default constructor to private

private Foo() { }

public static readonly Foo Only = new Foo();

public object DoFunctionality();

}

The above method is short and simple. Here are the important things to take away:
(1) no public constructors: The point is to share instances, not to let people create their own. The lack of public constructors indicates to developers that this is not your “run of the mill” type.
(2) immutable, immutable, immutable! nine times out of ten you don't want anything you do to this object to affect other code, threads, etc., in some inadvertent manner. Another word for this is to make your type a functional type (no new ideas to functional programmers, who are used to dealing with singletons all the time).

A more common thing that people will find in the .NET libraries is this implementation:

class Foo {

// change the default constructor to private

private Foo() { }

private static readonly Foo sharedOnly = new Foo();

public static Foo Only {

get { return sharedOnly; }

}

public object DoFunctionality();

}

It hides the shared instance of Foo behind a property. Library developers may choose this implementation since allows them to decide later exactly how to return their singleton instance. In fact, in the gang of four design patterns book, the template they outlined is more similar to this, since their examples are in C++.

Another point to take in mind in regards to hiding your instance behind a property (or a method call) is that the compiler can no longer prove that two different accesses will always return the same instance of the object. It's then up to users of this type to trust the implementation, but then again, it's another possible “bug” if your design explicitly wants only ONE instance.

Yet another common thing to do, if you've decided to abstract out the singleton behind a property is to delay its creation until needed, like so:

class Foo {

// change the default constructor to private

private Foo() { }

private static Foo sharedOnly = null;

public static Foo Only {

get {

return (sharedOnly != null) ? sharedOnly :

(sharedOnly = new Foo());

}

public object DoFunctionality();

}

Some people may not like the ternary (? :) expression, or the assignment used as an expression, but I think it's perfectly legit in something this simple. What you'll notice changed is the removal of the readonly attribute, since you're instantiating on demand. Although you're arguably gaining since you don't instantiate objects that you don't need for sure, you're also still opening yourself up for bugs by removing the readonly attribute (such as accidentally setting that field).

If you don't care about getting back the exact same instance, you may wish to statically refer to something similar to the lazy loader posted to JayBaz's blog, written by Cyrus, before he got his own blog. But stay tuned to why I think IOptional<T> should be implemented differently. It's been a little over the 48 hours Cyrus promised me to write this all up, but I've since then gotten an extension until morning :-P.

Others may point out that using either of the examples that employ the use of properties may slow down the program since you're actually executing code whenever you reference a property -- but this is usually trivial overhead, and one can probably assume that the JIT will optimize out the function call.

I bet you're probably thinking that I'm beating a dead horse, but I wanted to make sure to cover a lot of possible design choices and the pros and cons of each. Next concept in the slate: unions.

Coming up: Design Patterns

TheoY — Fri, 21 May 2004 05:07:00 GMT

Quick detour (not so much of a detour).

Cyrus has challenged me to 48 hours in order to expound on how he could've written is IOptional<T> better. Actually, I started to explain some of my suggestions, but now he's imposed this limit, since he's too antsy for me to really finish writing out my entire rationale.

So instead of writing real code, we're going to talk more about design and theory for a while... but I have a couple of caveats.

(1) I'm going to assume that you're already familiar with programming in .NET, and my samples will mostly be in C# (though they certainly can be ported to other .NET flavors).
(2) I'm also going to assume that you're comfortable with the semantics for single class-inheritance, as well as virtual methods. Most of the material won't be directed towards explaining the semantics of the .NET language features, but more along the line of the question, “How do I use this the right way?”.
(3) Virtual methods are prolific throughout abstracted/generalized object oriented programs. These are slower than “non-virtual” methods, but they also buy a lot of abstraction and scalability in design. Most people will also agree that the “performance hit” is marginal, and the payoff is quite valuable in development time, code complexity, and sustainability.
(4) Most of the examples I'll be writing will not consider thread-safety, which is usually its own can of worms. The main reason is that for most of the upcoming examples, you can workaround thread-safety by giving each thread separate copies (unless they're supposed to share), or you can wrap synchronization logic using decorators.

With that in mind, let's begin with the singleton pattern.

Singleton Pattern: http://blogs.msdn.com/theoy/archive/2004/05/20/136528.aspx