C# – Is it possible to throw compiler error when attempting to use an unimplemented method

cvisual studio

The backstory is long but the general idea is that I'm beginning an iterative refactoring process to replace a poorly designed data access layer with a new one under constraints from above. We can't fix everything at once but need to slowly phase in the new changes.

The old DAL contains several classes each containing several data access methods. The new DAL must preserve the method signatures and return types of the old DAL, and the old DAL code must be retained through the refactor. In a way you could say that we're implementing a repository pattern after the fact but also hard coding the dependencies on a method by method basis instead of injecting them at runtime.

A nice way to go about the refactor is with VS Quick Actions. I can easily extract an interface from each of the old classes through the designer and then auto-implement them for the new classes. This creates a new class with the same method signatures of the old class; however the new methods are initially just stubs that throw a NotImplementedException until they are filled with an implementation.

The trouble is that the NotImplementedException is only thrown at runtime whereas I really need it at compile time. Is there a pattern that can be used to allow us to stub out the new DAL methods but raise a compiler error if we attempt to use them before they are in fact implemented?

Best Answer

Someone had posted earlier about the Obsolete attribute, which can be configured to throw an compile error when attempting to use a method that is decorated as such. I don't know why that answer got deleted but it works perfectly for my purposes. Thanks, whoever you are!

    [Obsolete("This method has not yet been implemented.", true)]
    public IList<object> MyMethod()
    {
        throw new NotImplementedException();
    }

Related Solutions

C# – Extension objects pattern

I think that you missed a little bit of the point of the article. When he was talking about think in the Extension, he was talking about an concept, and not a particular Design Pattern. There are several Design Patterns that would allow for extension of your objects, this really depends on how you want to do it. Let me quote what 2 think could be the best to allow for extension:

Decorator Pattern:

private interface IPrice
{
    int Price { get; }
}

private class PriceDecorator : Pizza
{
    IPrice _price;

    protected virtual int OriginalPrice { get { return 0; } }

    public virtual int Price
    {
        get { return OriginalPrice + _price.Price; }
    }
    protected PriceDecorator() { }

    public PriceDecorator(IPrice price)
        : this()
    {
        _price = price;
    }
}

private class Pizza : PriceDecorator
{
    public Pizza(IPrice price) : base(price){}
    protected Pizza()  { }

    protected override int OriginalPrice
    {
        get { return 10; }
    }
}

class Cheese : PriceDecorator
{
    protected Cheese()  {    }
    public Cheese(IPrice price) : base(price) { }

    protected override int OriginalPrice
    {
        get { return 2; }
    }
}

class Pepperoni : PriceDecorator
{
    protected Pepperoni() {}
    public Pepperoni(IPrice price) : base(price){ }

    protected override int OriginalPrice
    {
        get { return 1; }
    }
}

class test
{
    void run()
    {
        var pizzaWithCheese = new Pizza(new Cheese());
        var pizzaWithCheeseAndPepperoni = new Pizza(new Cheese(new Pepperoni()));
    }
}

Strategy Design Pattern:

You can read more here

abstract class StrategyBase
{
    public abstract void DoSomething();
}

class ConcreteStrategyA : StrategyBase
{
    public override void DoSomething()
    {
        Console.WriteLine("Called ConcreteStrategyA.DoSomething()");
    }
}

class ConcreteStrategyB : StrategyBase
{
    public override void DoSomething()
    {
        Console.WriteLine("I did something!");
    }
}

/// This is the class that you allow extension, using any of the strategies 
class Context
{
    private StrategyBase _strategy;

    public Context(StrategyBase strategy)
    {
        this._strategy = strategy;
    }

    public void DoSomething()
    {
        _strategy.DoSomething();
    }
}

// Use it like this:
var c = new Context(new ConcreteStrategyA());
c.DoSomething();

C# – Help with Inheritance Hierarchy Design

You have created your own, unnecessary problem here.

Everything must be runnable
The default implementation of run requires proc
Anybody implementing their own run can ignore proc (but all that useless code still adorns the class and any descendants).
Your concrete, exception-throwing implementation of proc enables people to set up themselves up for runtime errors. Why do that?

OK, so you wanted to be helpful by providing a default implementation but you have bolted on implementation details which you know will not always be desired. You say you want to avoid code duplication but you have encumbered your hierarchy with code which will be obsolete as soon as somebody extends it.

I would strongly urge you to go the interface/abstract-base-class route here:

Abstract base class runnable
Abstract base class proccer
Create proc-calling concrete implementation of runnable.
Wherever possible (even in proc-caller class methods) refer to runnables and not proc-callers).

So your default run implentation can be used where desired but can be dropped without penalty. Also, this way people are forced to implement proc if they mix in proc-caller but you don't have to write that "Not implemented" version of proc - they can't compile their code if they do not implement proc. Why create that runtime trap when you can require them to fix things at compile time?

If you think there are other useful behaviours which should be available, you can avoid code duplication by providing "interfaces" in the same way I have shown for proc. Anybody who wants that can mix it in.

Best Answer

Related Solutions

C# – Extension objects pattern

C# – Help with Inheritance Hierarchy Design

Related Topic