Denominazione dell'interfaccia: prefisso 'Can-' vs suffix '-Abile'

Forse vuoi essere in grado?

Alcuni esempi da .Net:

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

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

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

EDIT: come indicato, la domanda riguardava le interfacce, non le proprietà.

In tal caso, non riesco a trovare alcuna interfaccia denominata Can-. Le interfacce tendono a essere sempre utilizzabili. Sarei d'accordo con questa terminologia. Un metodo può richiedere come parametro un ISerializable object o IPrintable document . Chiedere un ICanBeSerialized object o un ICanBePrinted document è molto difficile da leggere.

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

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

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

In termini grammaticali, "canFoobar" è un predicato, mentre "Foobarable" è un aggettivo o un sostantivo (di solito un nome nel contesto di un'API).

Notate anche la sottile differenza: -possibile implica un ruolo passivo per il nome al quale è applicata, cioè, se Qualcosa è Foobarable, quindi può essere soppiantato da qualcos'altro; can- implica un ruolo attivo, cioè, se qualcosa può fare Foobar, allora può fobare qualcos'altro. Oppure, da una diversa angolazione: se A può eseguire il foobar B, quindi A.canFoobar() e B is Foobarable .

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

instance.canFoobar();

class Something implements Foobarable { ... }

Personalmente rimango con la versione -able. Ecco la mia ragione: la maggior parte (tutti?) Gli editor grafici suggeriscono identificatori basati su ciò che hai digitato. Sebbene alcuni di essi siano abbastanza "intelligenti" da cercare anche all'interno degli identificatori, alcuni offrono ancora solo l'inizio della ricerca degli identificatori.

Per velocizzare la digitazione, vorrai abbreviare la lista di identificatori suggeriti con il minor numero possibile di tasti. Più identificatori hanno lo stesso inizio, ad es. 'ICan-' più caratteri dovrai digitare.

Se pensi che questo non sia un problema nel tuo caso, allora è grandioso e ti consiglierei di usare altri criteri per scegliere una convenzione di denominazione. In alcuni casi, ad es. nel nostro team, preferiamo gli identificatori che distinguono dopo il minor numero di battute possibile.

A parte questo, consiglierei di utilizzare la convenzione di denominazione che rende il codice più comprensibile per chi lavora al progetto. Avere una conversazione all'interno della tua squadra. Non c'è giusto o sbagliato in quanto tale. Solo convenzioni che funzionano e convenzioni che funzionano di 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 indicazioni di un'azione.

L'uso e le preferenze attuali potrebbero tuttavia essere incoerenti a causa di molte ragioni.

L'azione viene eseguita di l'oggetto:
CanShoot - > È spara (a) qualcosa
CanFly - > E ' vola CanChange - > Cambia

L'azione viene eseguita on l'oggetto:
Leggibile - > Tu puoi leggerlo
Scrivibile - > Tu puoi scrivere (a) esso
Stampabile - > Tu puoi stamparlo

Anche se potrebbe non essere una regola o anche necessariamente logica, aiuta ad adottare la convenzione e mantenere la coerenza di utilizzo nella denominazione delle variabili.

Penso che potresti voler distinguere tra capacità e permesso. Mentre Serializable e CanSerialize implicano che qualcosa è in grado di essere serializzato, ci sono anche problemi di autorizzazione (o forse mancanza di spazio su disco) e potresti dover considerare MaySerialize . Lasciare le cose a ~able rimuove la necessità di distinguere tra can e may .

Quando sottoclassi / implementando interfacce penso che la regola generale sia che dovresti essere in grado di dire "B è una A" (dove B implementa A). Non sembra giusto dire:

A Document is a CanBePrinted

Ma sembra giusto (o almeno meglio) dire:

A Document is a Printable

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

Da MSDN:

"Assegna al nome delle proprietà booleane una frase affermativa (CanSeek anziché CantSeek). Opzionalmente, puoi anche anteporre le proprietà booleane a Is, Can o Has, ma solo dove aggiunge valore." link

A mio parere, la variante "-able" è molto più leggibile della tua proposta "CanDoSomething" che impone molte più gobbe di cammello.

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