Nombre de la interfaz: prefijo 'Can-' vs sufijo '-Able'

Es común usar '-able' como sufijo para interfaces, por ejemplo

Serializable Imprimible Enumerable Bebible Tirable Giratorio

Estaba pensando que 'Can-' podría ser mejor porque puede ser más descriptivo. Sí, es más prolijo y agrega ruido al nombre de la interfaz. En particular, se pueden usar verbos pasivos.

Por ejemplo, 1 Shootable significa que el objeto puede disparar (un arma podría implementar esto), o significa que puede dispararse (un tablero objetivo podría implementar esto). Con el prefijo 'Can-', el primero sería "CanShoot" y el último sería "CanBeShotAt" o "CanShootAt".

Ej. 2 Un documento 'CanBePrinted' y una impresora 'CanPrint'

¿O deberíamos seguir con '-Able' y dejar que la documentación proporcione el contexto?

Cualquier opinión

Quizás quieres Is-able?

Algunos ejemplos de .Net:

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

No parece haber un estándar uniforme. Ve con lo que se lee bien.

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

EDITAR: Como se señaló, la pregunta era sobre Interfaces, no Propiedades.

En ese caso, no puedo encontrar ninguna interfaz llamada Can-. Las interfaces tienden a ser siempre utilizables. Estoy de acuerdo con esta terminología. Un método puede solicitar como parámetro a ISerializable objecto IPrintable document. Pedir una ICanBeSerialized objecto una ICanBePrinted documentes muy difícil de leer.

Por otro lado, la Impresora, sugeriría simplemente llamar a la interfaz IPrinter. Su método le pedirá a IPrinter device.

Lea la firma del método a continuación en voz alta. (Personalmente, considero que el prefijo "I" es silencioso). ¿Se lee bien? ¿Suena bien?

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

Gramaticalmente hablando, "canFoobar" es un predicado, mientras que "Foobarable" es un adjetivo o un sustantivo (generalmente un sustantivo en el contexto de una API).

También tenga en cuenta la sutil diferencia: -able implica un papel pasivo para el sustantivo al que se aplica, es decir, si Algo es Foobarable, entonces puede ser engañado por otra cosa; can- implica un rol activo, es decir, si Something canFoobar, entonces puede foobar algo más. O, desde un ángulo diferente: si A puede foobar B, entonces A.canFoobar()y B is Foobarable.

En términos de expresividad OOP, asociaría predicados con métodos o propiedades, mientras que los sustantivos son clases o interfaces. Asi que:

instance.canFoobar();

class Something implements Foobarable { ... }

Personalmente, me quedaría con la versión de mesa. Aquí está mi razón: la mayoría de los editores gráficos (¿todos?) Sugieren identificadores basados ​​en lo que ha escrito. Aunque algunos de ellos son lo suficientemente "inteligentes" como para buscar también dentro de los identificadores, algunos todavía solo ofrecen comienzos de búsqueda de identificadores.

Para acelerar la escritura, le gustaría acortar la lista de identificadores sugeridos con la menor cantidad de teclas posible. Cuantos más identificadores tengan el mismo comienzo, por ejemplo, 'ICan-', más caracteres tendrá que escribir.

Si cree que esto no es un problema en su caso, entonces es genial y recomendaría usar otros criterios para elegir una convención de nomenclatura. En algunos casos, por ejemplo, en nuestro equipo, preferimos identificadores que distingan después de la menor cantidad de teclas posible.

Aparte de eso, recomendaría usar la convención de nomenclatura que hace que su código sea más comprensible para aquellos que trabajan en el proyecto. Ten una conversación dentro de tu equipo. No hay bien o mal como tal. Solo convenciones que funcionan y convenciones que funcionan menos.

No olvide que las buenas herramientas de refactorización le permiten cambiar el nombre de las cosas con la frecuencia que desee. Por lo tanto, es fácil experimentar con diferentes enfoques.

Claramente, el prefijo y el sufijo son opciones casi obvias para diferentes tipos de acciones o más bien, diferentes direcciones de una acción.

Sin embargo, el uso y las preferencias actuales pueden ser inconsistentes debido a muchas razones.

La acción se lleva a cabo por el objeto:
CanShoot -> It brotes (a) algo
CanFly -> Se vuela
canchange -> Se cambia

La acción se realiza en el objeto:
Legible -> Puede leerlo
Escribible -> Puede escribir (para)
Imprimible -> Puede imprimirlo

Si bien puede no ser una regla o incluso necesariamente lógico, ayuda a adoptar la convención y mantener la coherencia de uso en la asignación de nombres variables.

Creo que es posible que desee distinguir entre capacidad y permiso. Si bien Serializablee CanSerializeimplica que algo es capaz de ser serializado, también hay problemas de permisos (o tal vez falta de espacio en disco) y es posible que deba tener en cuenta MaySerialize. Dejar las cosas en ~ableelimina la necesidad de distinguir entre cany may.

Al subclasificar / implementar interfaces, creo que la regla general es que debería poder decir "B es una A" (donde B implementa A). No suena bien decir:

A Documentes unCanBePrinted

Pero suena bien (o al menos mejor) decir:

A Documentes unPrintable

Creo que tanto Xable en términos de gramática como de convenciones es mejor para nombres de interfaces, mientras que IsX, CanX, DoesX son mejores para nombres de propiedades.

Desde MSDN:

"Nombre las propiedades booleanas con una frase afirmativa (CanSeek en lugar de CantSeek). Opcionalmente, también puede prefijar las propiedades booleanas con Is, Can o Has, pero solo donde agrega valor". http://msdn.microsoft.com/en-us/library/ms229012.aspx

En mi opinión, la variante "-able" es mucho más legible que su propuesta "CanDoSomething" que impone muchas más jorobas de camello.

En Scala, *Ablese usa para interfaces, pero Can*se usa para el patrón de clase de tipo. Esencialmente, para poder llamar a ciertos métodos, debe existir un valor implícito de cierto tipo en su alcance. El nombre de este tipo a veces tiene el prefijo Can.