Nomeação da interface: prefixo 'Can-' vs sufixo '-Able'

É comum usar '-able' como sufixo para interfaces, por exemplo

Rotável Shootable potável enumerável imprimível serializável

Eu estava pensando que 'Can-' poderia melhorar porque pode ser mais descritivo. Sim, é mais prolixo e adiciona ruído ao nome da interface. Em particular, verbos passivos podem ser usados.

Por exemplo, 1 Shootable significa que o objeto é capaz de disparar (uma arma pode implementar isso) ou significa que pode ser atingido (uma placa de alvo pode implementar isso). Com o prefixo 'Can-', o primeiro seria "CanShoot" e o último seria "CanBeShotAt" ou "CanShootAt".

Por exemplo 2 Um documento 'CanBePrinted' e uma impressora 'CanPrint'

Ou devemos ficar com '-Able' e deixar a documentação fornecer o contexto?

Qualquer opinião.

Talvez você queira o Is-capaz?

Alguns exemplos de .Net:

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

Não parece haver um padrão uniforme. Vá com o que lê bem.

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

Edição: Como apontado, a pergunta era sobre interfaces, não propriedades.

Nesse caso, não consigo encontrar nenhuma interface chamada Can-. As interfaces tendem a sempre usar -able. Eu concordo com esta terminologia. Um método pode solicitar como parâmetro a ISerializable objectou IPrintable document. Pedir um ICanBeSerialized objectou um ICanBePrinted documenté muito estranho de ler.

Por outro lado, a impressora, sugiro simplesmente chamar a interface IPrinter. Seu método estará pedindo um IPrinter device.

Leia a assinatura do método abaixo em voz alta. (Pessoalmente, considero o prefixo "I" silencioso.) Ele lê bem? Isso soa certo?

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

Gramaticalmente, "canFoobar" é um predicado, enquanto "Foobarable" é um adjetivo ou um substantivo (geralmente um substantivo no contexto de uma API).

Observe também a diferença sutil: -able implica um papel passivo no substantivo ao qual é aplicado, ou seja, se Algo for Foobarable, ele poderá ser foobarred por outra coisa; pode implicar um papel ativo, isto é, se Algo puderFoobar, ele poderá foobar em outra coisa. Ou, de um ângulo diferente: se A puder foobar B, então A.canFoobar()e B is Foobarable.

Em termos de expressividade OOP, eu associaria predicados a métodos ou propriedades, enquanto substantivos são classes ou interfaces. Tão:

instance.canFoobar();

class Something implements Foobarable { ... }

Pessoalmente, eu continuaria com a versão -able. Aqui está o meu motivo: a maioria dos editores gráficos (todos?) Sugere identificadores com base no que você digitou. Embora alguns deles sejam 'inteligentes' o suficiente para também pesquisar nos identificadores, alguns ainda oferecem apenas o início da pesquisa dos identificadores.

Para acelerar a digitação, reduza a lista de identificadores sugeridos com o menor número possível de pressionamentos de tecla. Quanto mais identificadores tiverem o mesmo começo, por exemplo, 'ICan-', mais caracteres você precisará digitar.

Se você acha que isso não é um problema no seu caso, isso é ótimo e eu recomendaria o uso de outros critérios para escolher uma convenção de nomenclatura. Em alguns casos, por exemplo, em nossa equipe, preferimos identificadores que distinguem após o menor número de pressionamentos de tecla possível.

Além disso, eu recomendaria usar a convenção de nomenclatura que torna seu código mais compreensível para os que trabalham no projeto. Converse com sua equipe. Não existe certo ou errado como tal. Apenas convenções que funcionam e convenções que funcionam menos.

Não esqueça que boas ferramentas de refatoração permitem renomear as coisas quantas vezes você quiser. Portanto, é fácil experimentar diferentes abordagens.

Claramente, o prefixo e o sufixo são opções quase óbvias para diferentes tipos de ações ou melhor, diferentes direções de uma ação.

O uso e as preferências atuais podem ser inconsistentes devido a várias razões.

Ação é executada por objeto:
CanShoot -> It brotos (at) algo
CanFly -> Ele voa
CanChange -> Ele muda

A ação é executada no objeto:
Legível -> Você pode lê-lo
Gravável -> Você pode escrever (para)
Imprimível -> Você pode imprimi-lo

Embora possa não ser uma regra ou mesmo necessariamente lógica, ajuda a adotar a convenção e manter a consistência do uso na nomeação de variáveis.

Eu acho que você pode querer distinguir entre capacidade e permissão. Enquanto Serializablee CanSerializeimplica que algo é capaz de ser serializado, também há problemas de permissão (ou talvez a falta de espaço em disco) e você pode precisar de considerar MaySerialize. Deixar as coisas em ~ableremove a necessidade de distinguir entre cane may.

Ao subclassificar / implementar interfaces, acho que a regra é que você possa dizer "B é um A" (onde B implementa A). Não parece certo dizer:

A Documenté umCanBePrinted

Mas parece certo (ou pelo menos melhor) dizer:

A Documenté umPrintable

Eu acho que o Xable em termos de gramática e de convenções é melhor para nomes de interfaces, enquanto IsX, CanX, DoesX são melhores para nomes de propriedades.

Do MSDN:

"Nomeie propriedades booleanas com uma frase afirmativa (CanSeek em vez de CantSeek). Opcionalmente, você também pode prefixar as propriedades booleanas com Is, Can ou Has, mas apenas onde agregar valor." http://msdn.microsoft.com/en-us/library/ms229012.aspx

Na minha opinião, a variante "-able" é muito mais legível do que a proposta "CanDoSomething", que impõe muito mais camelôs.

No Scala, *Ableé usado para interfaces, mas Can*é usado para o padrão de classe de tipo. Essencialmente, para poder chamar determinados métodos, um valor implícito de um determinado tipo deve existir no escopo. Às vezes, o nome desse tipo é prefixado Can.