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

29

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.

MustafaM
źródło
Człowieku, użyj „-able”. Kropka.
Tulains Córdova
2
Użyj obu dlaclass Cannibal implements Can, Able {}
Thomas Eding,

Odpowiedzi:

18

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)
}
Hand-E-Food
źródło
2
Document.IsPrintable jest lepszy niż Document.CanBePrinted. O ile mogę stwierdzić, używali - aby uniknąć biernego głosu.
Thanos Papathanasiou,
„Można wydrukować” wydaje się być bardziej poprawnym angielskim niż „można wydrukować”.
Danny Varod
1
„Głos pasywny jest używany, gdy koncentruje się na akcji. Nie jest jednak ważne ani nie wiadomo, kto lub co wykonuje akcję”. Mogę tylko zgadywać, że chcieli skupić się na obiekcie, a nie na akcji. Jeśli więc „Type.IsSerializable” zgłosi wyjątek, jest to wina typu. nie metody ”, ale jeśli„ Type.CanBeSerialized ”zgłosi wyjątek, to obwinisz metodę, a nie typ. Wprawdzie różnica jest niewielka, ale jest.
Thanos Papathanasiou
3
Widzę, że to zaakceptowana odpowiedź, ale to nie odpowiada na pytanie PO. Podane przykłady to nazwy właściwości . OP prosi o konwencji nazewnictwa dla interfejsu nazwami, takimi jak ISerializable, IDataErrorInfoi INotifyPropertyChanged.
Kevin McCormick
@KevinMcCormick, dobry punkt! Powyższe zmiany.
Hand-E-Food
23

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 { ... }
tdammers
źródło
7

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.

Manfred
źródło
1
+1. Moje rozumowanie byłoby takie samo, umieść czasownik kontrolny na pierwszym miejscu, aby ułatwić wyszukiwanie / znajdowanie / sortowanie w IDE.
pap.
1
w ten sposób działa nie tylko intellisense, ale także skanowany przez człowieka tekst, prefiksy sprawiają, że kod jest mniej czytelny
jk.
7

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.

Kris
źródło
4

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.

Tangurena
źródło
SerializableIfNotDiskFullAndIfNotPermissionMissing ... Lol :)
Max
2

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

Gyan alias Gary Buyn
źródło
2

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

Danny Varod
źródło
+1 za pomocny link; Nigdy nie mogę wymyślić, jak to nazwać
CamelBlues
0

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

Jaskółka oknówka
źródło
1
a Can- to raczej nazwa metody
maniak zapadkowy
Nazwa właściwości - patrz MSDN. Nazwy metod powinny być „czasownikami lub wyrażeniami czasownikowymi”. Poza tym, co jest nie tak z wieloma garbami?
Danny Varod
0

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.

axel22
źródło
Can * nie jest dobrym imieniem dla klasy. Cytat z MSDN: „Twórz klasy nazw, interfejsy i typy wartości za pomocą rzeczowników, wyrażeń rzeczownikowych lub czasami przymiotników, używając obudowy Pascala”, link: msdn.microsoft.com/en-us/library/ms229040.aspx Dobra nazwa klasą będzie Dokument, akceptowalna nazwa nadająca się do wydruku.
Danny Varod
Jednym z przykładów w języku Scala jest CanBuildFrom. To byłoby przymiotnik. Przypadek użycia tej klasy jest bardzo różny od przypadku innych klas. Wystąpienia tej klasy prawie nigdy nie są konstruowane ani rozwiązywane przez klienta - raczej są dostępne w zakresie dla niektórych typów. Jeśli są dostępne dla określonego typu, można wywołać metody obejmujące ten typ, które są oznaczone jako wymagające tej klasy. Ma to na celu zaoferowanie mechanizmu elastyczności bardziej elastycznego niż subtyping. Zobacz scala-lang.org/node/114 .
axel22
Pamiętam tylko, używając wyrażeń przymiotnikowych dla próbnych klas implementujących interfejsy do testów jednostkowych - ponieważ nie odgrywały one żadnej roli.
Danny Varod