Posso forçar subclasses para substituir um método sem torná-lo abstrato?

Question

Eu tenho uma classe com alguns métodos abstratos, mas eu quero ser capaz de editar uma subclasse dessa classe no designer. No entanto, o designer não pode editar a subclasse a menos que possa criar uma instância da classe pai. Então, meu plano é substituir os métodos abstratos com topos e marcá-los como virtual -. Mas então se eu fizer outra subclasse, eu não vou receber um erro de tempo de compilação se eu esquecer de implementá-las

Existe uma maneira de marcar os métodos para que eles têm de ser implementadas por subclasses, sem marcá-los como abstrato?

Answer 1

Bem, você poderia fazer algum código envolvendo #if realmente confuso - ou seja, na DEBUG é virtual (para o designer), mas em RELEASE é abstrato. A verdadeira dor de manter, apesar de tudo.

Mas para além disso: basicamente, não. Se você quiser suporte de designer não pode ser abstrato, de modo que você é deixado com "virtual" (presumivelmente com o método base jogando um NotImplementedException).

É claro, os testes de unidade irá verificar que os métodos têm sido implementadas, sim? ;-p

Na verdade, provavelmente seria bastante fácil de teste via genéricos - ou seja, ter um método de teste genérico da forma:

[Test]
public void TestFoo() {
  ActualTest<Foo>();
}
[Test]
public void TestBar() {
  ActualTest<Bar>();
}

static void ActualTest<T>() where T : SomeBaseClass, new() {
  T obj = new T();
  Assert.blah something involving obj
}

Answer 2

Você pode usar a referência ao idioma implementação em sua classe.

public class DesignerHappy
{
    private ADesignerHappyImp imp_;

    public int MyMethod()
    {
        return imp_.MyMethod()    
    }

    public int MyProperty
    {
        get { return imp_.MyProperty; }
        set { imp_.MyProperty = value; }
    }
}

public abstract class ADesignerHappyImp
{
    public abstract int MyMethod();
    public int MyProperty {get; set;}
}

DesignerHappy apenas expõe a interface que quiser, mas encaminha todas as chamadas para o objeto de implementação. Você estender o comportamento de sub-classificar ADesignerHappyImp, o que obriga a implementar todos os membros abstratos.

Você pode fornecer uma implementação padrão de ADesignerHappyImp, que é usado para inicializar DesignerHappy por padrão e expor uma propriedade que lhe permite alterar a implementação.

Answer 3

Note que "DesignMode" não está definido no construtor. É definido após VS analisa os InitializeComponents () método.

Answer 4

Eu sei que não é bem o que você está depois, mas você pode fazer todos os seus topos na classe base atirar a NotImplementedException. Então, se qualquer um dos seus subclasses não substituído-los você teria uma exceção tempo de execução quando o método na classe base é chamado.

Answer 5

A classe Component contém uma propriedade booleana chamada "DesignMode" que é muito útil quando você quer que seu código para se comportar de forma diferente no designer do que em tempo de execução. Pode ser de alguma utilidade neste caso.

Answer 6

Como regra geral, se não há nenhuma maneira em uma linguagem para fazer algo que geralmente significa que há uma boa razão conceitual para não fazê-lo.

Às vezes, esta será a culpa dos projetistas da linguagem - mas não muitas vezes. Normalmente eu acho que eles sabem mais sobre design de linguagem do que eu; -)

Neste caso, você quer um método virtual substituído pela ONU para lançar uma exceção tempo de compilação (em vez e um tempo de execução um). Basicamente um método abstrato em seguida.

Fazendo métodos virtuais se comportam como os abstractos está indo só para criar um mundo de confusão para você mais abaixo da linha.

Por outro lado, a ficha VS em design não é frequentemente bastante ao mesmo nível (que é um pouco injusto, mas certamente menos rigor é aplicado do que está em fase de projeto de linguagem - e com razão). Algumas ferramentas VS, como o designer de classe e editores WPF atuais, são boas idéias, mas não é realmente completa - ainda.

No caso em que você está descrevendo Acho que você tem um argumento para não usar o designer de classe, não um argumento para cortar o seu código.

Em algum momento (talvez na próxima VS) eles vão arrumar como o designer classe lida com classes abstratas, e então você vai ter um corte com nenhuma idéia por que ele foi codificado dessa forma.

Deve ser sempre o último recurso para cortar o seu código para caber o designer, e quando você tentar manter hacks mínima. Acho que é geralmente melhor ter concisa, código legível que faz sentido rapidamente código sobre bizantina que as obras do atual ferramentas quebradas.

Answer 7

Para usar ms como um exemplo ...

Microsoft faz isso com os modelos de controle de usuário em Silverlight. #if é perfeitamente aceitável e é duvidoso o ferramental vai trabalhar em torno dele tão cedo. IMHO