Intro

At times I find myself running into name collisions when writing code. This can occur based on a class name being shared between referenced dlls within a project.

In this example, I will introduce ambiguity between class names within a single project:

SolutionExplorer

The classes

We can define one class as follows:

using System;

namespace MotoLens.Model
{
    class Photo
    {
        public bool SomethingDone { get; private set; }

        internal void DoSomething() => SomethingDone = true;
    }
}

Thus, we can define another class as follows:

namespace MotoLens.View.Support
{
    public class Photo { }
}

Resolving Ambiguity

If we have a class that references both Photo classes then we usually provide a qualified path to the class that we want to reference.

Here’s an example that requires qualified paths to a class:

using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Tests
{
    [TestClass]
    public class MyTest
    {
        [TestMethod]
        public void some_test1()
        {
            // Setup
            var photo = new MotoLens.Model.Photo();

            // Test
            photo.DoSomething();

            // Verify
            Assert.IsTrue(photo.SomethingDone);
        }

        [TestMethod]
        public void some_test2()
        {
            // Setup
            var photo = new MotoLens.View.Support.Photo();

            // Test
            var photoRepository = new List<MotoLens.View.Support.Photo> { photo };

            // Verify
            Assert.IsNotNull(photoRepository.Single());
        }
    }
}

Here’s a different view:

QualifiedPaths

An Alternative Resolution to Ambiguity

Instead of using fully qualified names to identify a class, we can use aliases.

using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MotoLens.Model;

namespace Tests
{
    using PhotoSupport = MotoLens.View.Support.Photo;

    [TestClass]
    public class MyTest
    {
        [TestMethod]
        public void some_test1()
        {
            // Setup
            var photo = new Photo();

            // Test
            photo.DoSomething();

            // Verify
            Assert.IsTrue(photo.SomethingDone);
        }

        [TestMethod]
        public void some_test2()
        {
            // Setup
            var photo = new PhotoSupport();

            // Test
            var photoRepository = new List<PhotoSupport> { photo };

            // Verify
            Assert.IsNotNull(photoRepository.Single());
        }
    }
}

Here’s an annotated view:

Alias

I think this solution enhances readability and is a lot cleaner than using a qualified path to a class.

Conclusion

In conclusion, I find myself at times running into name collisions when writing code. This can occur based on a class name being shared between referenced dlls within a project. I have identified the usage of aliases to alleviate this ambiguity.

Advertisements