Denominazione dell'interfaccia: prefisso 'Can-' vs suffisso '-Able'

È comune usare '-able' come suffisso per interfacce es

Girabile con numero di serie stampabile serializzabile stampabile serializzabile

Pensavo che "Can-" potesse migliorare perché potrebbe essere più descrittivo. Sì, è più prolisso e aggiunge rumore al nome dell'interfaccia. In particolare, possono essere usati verbi passivi.

Ad esempio 1 sparare significa che l'oggetto è in grado di sparare (una pistola potrebbe implementarlo) o significa che può essere sparato (una scheda bersaglio potrebbe implementarlo). Con il prefisso 'Can-', il primo sarebbe "CanShoot" e il secondo sarebbe "CanBeShotAt" o "CanShootAt".

Ad es. 2 Un documento "CanBePrinted" e una stampante "CanPrint"

Oppure, dovremmo attenerci a '-Able' e lasciare che la documentazione fornisca il contesto?

Qualsiasi opinione

Forse vuoi Is-capace?

Alcuni esempi da .Net:

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

Non sembra esserci uno standard uniforme. Vai con ciò che legge bene.

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

EDIT: Come sottolineato, la domanda riguardava le interfacce, non le proprietà.

In tal caso, non riesco a trovare alcuna interfaccia chiamata Can-. Le interfacce tendono sempre a essere utilizzabili. Concordo con questa terminologia. Un metodo può richiedere come parametro a ISerializable objecto IPrintable document. Chiedere a ICanBeSerialized objecto a ICanBePrinted documentè molto scomodo da leggere.

Dall'altro lato, la stampante, suggerirei semplicemente di chiamare l'interfaccia IPrinter. Il tuo metodo chiederà a IPrinter device.

Leggi la firma del metodo qui sotto ad alta voce. (Personalmente, considero il prefisso "I" come silenzioso.) Legge bene? Suona bene?

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

Grammaticamente parlando, "canFoobar" è un predicato, mentre "Foobarable" è un aggettivo o un sostantivo (di solito un sostantivo nel contesto di un'API).

Nota anche la sottile differenza: -able implica un ruolo passivo al nome a cui è applicato, cioè se Qualcosa è Foobarable, allora può essere fobato da qualcos'altro; può implicare un ruolo attivo, vale a dire, se qualcosa è in grado di goobar, allora può fobare qualcos'altro. Oppure, da un'angolazione diversa: se A può foobar B, allora A.canFoobar()e B is Foobarable.

In termini di espressività OOP, assocerei predicati a metodi o proprietà, mentre i nomi sono classi o interfacce. Così:

instance.canFoobar();

class Something implements Foobarable { ... }

Personalmente rimarrei con la versione -able. Ecco la mia ragione: la maggior parte (tutti?) Gli editor grafici suggeriscono identificatori in base a ciò che hai digitato. Sebbene alcuni di essi siano abbastanza "intelligenti" da cercare anche all'interno di identificatori, alcuni offrono comunque solo inizi di ricerca di identificatori.

Per accelerare la digitazione, si desidera abbreviare l'elenco degli identificatori suggeriti con il minor numero possibile di tasti. Più identificatori hanno lo stesso inizio, ad es. "ICan-" più caratteri dovrai digitare.

Se ritieni che questo non sia un problema nel tuo caso, è fantastico e consiglierei di utilizzare altri criteri per scegliere una convenzione di denominazione. In alcuni casi, ad esempio nel nostro team, preferiamo identificatori che si distinguono dopo il minor numero di tasti possibile.

A parte ciò, consiglierei di utilizzare la convenzione di denominazione che rende il codice più comprensibile per coloro che lavorano al progetto. Fai una conversazione nella tua squadra. Non esiste giusto o sbagliato in quanto tale. Solo convenzioni che funzionano e convenzioni che funzionano meno.

Non dimenticare che i buoni strumenti di refactoring ti consentono di rinominare le cose tutte le volte che vuoi. Quindi è facile sperimentare approcci diversi.

Chiaramente il prefisso e il suffisso sono scelte quasi ovvie per diversi tipi di azioni o, piuttosto, diverse direzioni di un'azione.

Tuttavia, l'utilizzo e le preferenze attuali potrebbero essere incoerenti a causa di molte ragioni.

Azione viene eseguita per l'oggetto:
CanShoot -> It germogli (at) qualcosa
CanFly -> Si vola
CanChange -> Si cambia

Azione viene eseguita sul l'oggetto:
leggibile -> Si può leggere
scrivibile -> È possibile scrivere (a) è
stampabile -> È possibile stamparlo

Sebbene possa non essere una regola o anche necessariamente logico, aiuta ad adottare la convenzione e a mantenere la coerenza d'uso nella denominazione delle variabili.

Penso che potresti voler distinguere tra capacità e autorizzazione. Mentre Serializablee CanSerializeimplica che qualcosa sia in grado di essere serializzato, ci sono anche problemi di autorizzazione (o forse mancanza di spazio su disco) e potrebbe essere necessario prendere in considerazione MaySerialize. Lasciare le cose a posto ~ableelimina la necessità di distinguere tra cane may.

Quando si esegue la sottoclasse / implementazione delle interfacce, penso che la regola empirica sia che si dovrebbe essere in grado di dire "B è a A" (dove B implementa A). Non sembra giusto dire:

A Documentè aCanBePrinted

Ma sembra giusto (o almeno meglio) dire:

A Documentè aPrintable

Penso che sia Xable sia per quanto riguarda la grammatica che per convenzione sia migliore per i nomi delle interfacce, mentre IsX, CanX, DoesX sono migliori per i nomi delle proprietà.

Da MSDN:

"Assegna un nome alle proprietà booleane con una frase affermativa (CanSeek invece di CantSeek). Facoltativamente, puoi anche aggiungere un prefisso alle proprietà booleane con Is, Can o Has, ma solo dove aggiunge valore." http://msdn.microsoft.com/en-us/library/ms229012.aspx

Secondo me la variante "-able" è molto più leggibile della tua proposta "CanDoSomething" che impone molte più gobbe di cammello.

In Scala, *Ableviene utilizzato per le interfacce, ma Can*viene utilizzato per il modello di classe di tipo. In sostanza, per poter chiamare determinati metodi, deve esistere un ambito implicito di un certo tipo. Il nome di questo tipo è talvolta preceduto da Can.