Nazwy interfejsu: przedrostek „Can-” vs sufiks „-Able”

Często używa się „-able” jako sufiksu dla interfejsów, np

Numerowalny drukowalny, wymienny, pijalny, strzelalny, obrotowy

Myślałem, że „Can-” może być lepsze, ponieważ może być bardziej opisowe. Tak, jest bardziej pracowity i dodaje szum do nazwy interfejsu. W szczególności można stosować czasowniki pasywne.

Np. 1 oznacza Strzelanie oznacza, że ​​obiekt jest w stanie strzelać (broń może to zaimplementować), czy oznacza to, że można go strzelić (tablica docelowa może to zaimplementować). Z prefiksem „Can-”, pierwszy z nich to „CanShoot”, a drugi to „CanBeShotAt” lub „CanShootAt”.

Np. 2 Dokument „CanBePrinted” i drukarka „CanPrint”

Czy też powinniśmy trzymać się „-Able” i pozwolić, aby dokumentacja zawierała kontekst?

Wszelkie opinie.

Być może chcesz Is-stanie?

Kilka przykładów z .Net:

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

Wydaje się, że nie ma jednolitego standardu. Idź z tym, co dobrze czyta.

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

EDYCJA: Jak już wspomniano, pytanie dotyczyło interfejsów, a nie właściwości.

W takim przypadku nie mogę znaleźć żadnych interfejsów o nazwie Can-. Interfejsy mają zawsze możliwość użycia. Zgodziłbym się z tą terminologią. Metoda może zażądać jako parametru a ISerializable objectlub IPrintable document. Pytanie o a ICanBeSerialized objectlub a ICanBePrinted documentjest bardzo niewygodne do czytania.

Z drugiej strony, Drukarka, sugerowałbym po prostu wywołanie interfejsu IPrinter. Twoja metoda poprosi o IPrinter device.

Przeczytaj na głos podpis metody poniżej. (Osobiście uważam, że przedrostek „ja” jest cichy.) Czy dobrze się czyta? Czy to brzmi dobrze?

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

Gramatycznie „canFoobar” jest predykatem, podczas gdy „Foobarable” jest przymiotnikiem lub rzeczownikiem (zwykle rzeczownik w kontekście API).

Zwróć też uwagę na subtelną różnicę: -able oznacza bierną rolę w rzeczowniku, do którego jest stosowany, to znaczy, jeśli coś jest możliwe do spłaszczenia, to może być spłaszczone przez coś innego; może implikować aktywną rolę, to znaczy, jeśli Coś może Fobobar, to może foobarować coś innego. Lub pod innym kątem: jeśli A może foobarować B, to A.canFoobar()i B is Foobarable.

Pod względem ekspresji OOP predykaty kojarzą mi się z metodami lub właściwościami, podczas gdy rzeczowniki są klasami lub interfejsami. Więc:

instance.canFoobar();

class Something implements Foobarable { ... }

Osobiście trzymałbym się wersji -able. Oto mój powód: większość (wszystkich?) Edytorów graficznych sugeruje identyfikatory na podstawie tego, co wpisałeś. Chociaż niektóre z nich są wystarczająco „inteligentne”, aby wyszukiwać w obrębie identyfikatorów, niektóre nadal oferują tylko początkowe wyszukiwania identyfikatorów.

Aby przyspieszyć pisanie, skróć listę sugerowanych identyfikatorów za pomocą jak najmniejszej liczby naciśnięć klawiszy. Im więcej identyfikatorów ma ten sam początek, np. „ICan”, tym więcej znaków będzie trzeba wpisać.

Jeśli uważasz, że to nie jest problem w twoim przypadku, to świetnie i polecam użycie innych kryteriów, aby wybrać konwencję nazewnictwa. W niektórych przypadkach, np. W naszym zespole, preferujemy identyfikatory, które rozróżniają się po jak najmniejszej liczbie naciśnięć klawiszy.

Poza tym polecam stosowanie konwencji nazewnictwa, która sprawia, że ​​Twój kod jest najbardziej zrozumiały dla osób pracujących nad projektem. Rozmawiaj w swoim zespole. Nie ma dobra ani zła jako takiego. Tylko konwencje, które działają i konwencje, które działają mniej.

Nie zapominaj, że dobre narzędzia do refaktoryzacji pozwalają ci zmieniać nazwy rzeczy tak często, jak chcesz. Łatwo jest więc eksperymentować z różnymi podejściami.

Oczywiście prefiks i sufiks są prawie oczywistymi wyborami dla różnych rodzajów akcji, a raczej różnych kierunków akcji.

Obecne użycie i preferencje mogą być niespójne z wielu powodów.

Akcja odbywa się poprzez obiektu:
canShoot -> It pędy (at) coś
CanFly -> To leci
CanChange -> To zmienia

Na obiekcie wykonywana jest czynność :
Czytelny -> Możesz go przeczytać
Zapisywalny -> Możesz napisać (do) Do
druku -> Możesz go wydrukować

Chociaż może to nie być reguła, a nawet niekoniecznie logiczna, pomaga przyjąć konwencję i zachować spójność użycia w nazwach zmiennych.

Myślę, że możesz chcieć odróżnić zdolność od pozwolenia. Choć Serializablei CanSerializesugerować, że coś może być w odcinkach, istnieją również kwestie uprawnień (albo brak miejsca na dysku) i może trzeba rozważyć MaySerialize. Pozostawienie rzeczy ~ableeliminuje potrzebę rozróżnienia między cani may.

Wydaje mi się, że podczas tworzenia podklasy / implementacji interfejsów powinieneś być w stanie powiedzieć „B to A” (gdzie B implementuje A). Mówienie:

A Documentjest aCanBePrinted

Ale brzmi dobrze (a przynajmniej lepiej) powiedzieć:

A Documentjest aPrintable

Myślę, że zarówno pod względem gramatycznym, jak i konwencyjnym Xable jest lepszy dla nazw interfejsów, podczas gdy IsX, CanX, DoesX są lepsze dla nazw właściwości.

Z MSDN:

„Nazwij właściwości boolowskie frazą twierdzącą (CanSeek zamiast CantSeek). Opcjonalnie możesz również poprzedzić właściwości boolowskie Is, Can, lub Has, ale tylko tam, gdzie dodaje wartości.” http://msdn.microsoft.com/en-us/library/ms229012.aspx

Moim zdaniem wariant „-able” jest znacznie bardziej czytelny niż proponowany „CanDoSomething”, który nakłada znacznie więcej garbów wielbłądów.

W Scali *Ablejest używany do interfejsów, ale Can*jest używany do wzorca klasy typów. Zasadniczo, aby móc wywoływać określone metody, musi istnieć ukryta wartość określonego typu. Nazwa tego typu jest czasami poprzedzona prefiksem Can.