Czy nazwy interfejsów powinny zaczynać się od prefiksu „I”?

Czytam „ Czysty kod ” Roberta Martina, aby, mam nadzieję, zostać lepszym programistą. Chociaż jak dotąd żaden z nich nie był przełomowy, zmusił mnie do odmiennego myślenia o sposobie projektowania aplikacji i pisania kodu.

Jest jedna część książki, z którą nie tylko się nie zgadzam, ale nie ma dla mnie sensu, szczególnie w odniesieniu do konwencji nazewnictwa interfejsów. Oto tekst zaczerpnięty bezpośrednio z książki. Pogrubiłem ten aspekt, który wydaje mi się mylący i chciałbym wyjaśnić.

Wolę pozostawić interfejsy bez ozdób. Poprzednie I, tak powszechne w dzisiejszych legendarnych brodzikach, jest w najlepszym razie rozproszeniem, aw najgorszym przypadku zbyt dużą ilością informacji. Nie chcę, aby użytkownicy wiedzieli, że przekazuję im interfejs .

Może dlatego, że jestem tylko studentem, a może dlatego, że nigdy nie zajmowałem się programowaniem zawodowym lub zespołowym, ale chciałbym, aby użytkownik wiedział, że jest to interfejs. Istnieje duża różnica między implementacją interfejsu a rozszerzeniem klasy.

Moje pytanie sprowadza się więc do: „Dlaczego powinniśmy ukrywać fakt, że jakaś część kodu oczekuje interfejsu?”

Edytować

W odpowiedzi na odpowiedź:

Jeśli Twój typ to interfejs lub klasa to Twoja firma, a nie osoba korzystająca z Twojego kodu. Dlatego nie powinieneś ujawniać szczegółów swojego kodu w tym kodzie strony trzeciej.

Dlaczego nie powinienem „ujawniać” szczegółów tego, czy dany typ jest interfejsem czy klasą dla kodu strony trzeciej? Czy to nie jest ważne, aby zewnętrzny programista korzystający z mojego kodu wiedział, czy będą implementować interfejs, czy rozszerzać klasę? Czy różnice po prostu nie są tak ważne, jak chcę, żeby były w mojej pamięci?

Jeśli przestaniesz o tym myśleć, zobaczysz, że interfejs tak naprawdę nie różni się znacznie semantycznie od klasy abstrakcyjnej:

• Obie mają metody i / lub właściwości (zachowanie);
• Żaden nie powinien mieć nieprywatnych pól (danych);
• Żadnej z nich nie można utworzyć bezpośrednio;
• Pochodzenie od jednego oznacza implementowanie wszelkich metod abstrakcyjnych, które posiada, chyba że typ pochodny jest również abstrakcyjny.

W rzeczywistości najważniejsze różnice między klasami i interfejsami to:

• Interfejsy nie mogą mieć prywatnych danych;
• Członkowie interfejsu nie mogą mieć modyfikatorów dostępu (wszyscy członkowie są „publiczni”);
• Klasa może implementować wiele interfejsów (w przeciwieństwie do możliwości dziedziczenia tylko z jednej klasy bazowej).

Ponieważ jedyne szczególnie znaczące rozróżnienia między klasami i interfejsami dotyczą (a) prywatnych danych i (b) hierarchii typów - z których żadne nie robi najmniejszej różnicy dla osoby wywołującej - generalnie nie trzeba wiedzieć, czy typ jest interfejsem czy Klasa. Na pewno nie potrzebujesz wizualnego wskazania.

Istnieją jednak pewne narożne przypadki, o których należy pamiętać. W szczególności, jeśli używasz refleksji, przechwytywania, dynamicznych serwerów proxy / miksów, tkania kodu bajtowego, generowania kodu lub czegokolwiek, co wiąże się z bałaganem bezpośrednio z systemem pisania w środowisku lub samym kodem - wtedy jest to bardzo pomocne, a czasem konieczne, aby wiedzieć od razu bat, czy masz do czynienia z interfejsem czy klasą. Wyraźnie nie chcesz, aby Twój kod w tajemniczy sposób zawiódł, ponieważ próbowałeś dodać klasę zamiast interfejsu jako mixin.

Jednak w przypadku typowego, waniliowego, codziennego kodu logiki biznesowej rozróżnienia między klasami abstrakcyjnymi a interfejsami nie muszą być reklamowane, ponieważ nigdy nie wejdą w grę.

Biorąc to wszystko pod uwagę, staram się i tak prefiksować moje interfejsy C #, Iponieważ jest to konwencja .NET używana i zalecana przez Microsoft. A kiedy wyjaśniam konwencje kodowania nowemu programistowi, znacznie łatwiej jest po prostu korzystać z reguł Microsoftu niż wyjaśniać, dlaczego mamy własne „specjalne” reguły.

Pod wieloma względami spójność jest ważniejsza niż konwencja. Dopóki jesteś konsekwentny w swoich schematach nazewnictwa, nie będzie trudno z nimi pracować. Przedrostek łączy się z I, jeśli chcesz, lub po prostu pozostaw nazwę bez ozdoby, nie ma to dla mnie znaczenia, dopóki wybierzesz styl i pozostanie przy nim!

Książka jest pełna dobrych rzeczy, ale nadal dodawałbym „I” do nazwy interfejsu.

Wyobraź sobie, że masz public interface ILogdomyślną implementację public class Log.

Teraz, jeśli zdecydujesz się na to public interface Log, nagle musisz zmienić klasę Log na public class LogDefaultlub coś w tych liniach. Z jednej dodatkowej postaci przeszliście na siedem - to z pewnością marnotrawstwo.

Często istnieje cienka granica między teorią a praktyką. Teoretycznie jest to naprawdę dobry pomysł, ale w praktyce nie jest tak dobry.

Cóż, tu nie chodzi o implementację interfejsu czy rozszerzenie klasy. W takich przypadkach i tak wiesz, co robisz.

Jednak gdy kod strony trzeciej (inny moduł aplikacji na przykład) manipuluje danymi, kod ten nie powinien obchodzić się, jeśli prezentujesz interfejs lub klasę.

To jest cały punkt abstrakcji. Przedstawiasz temu kodowi zewnętrznemu obiekt określonego typu. Ten typ ma funkcję członka, którą możesz wywołać. Wystarczy.

Jeśli Twój typ to interfejs lub klasa to Twoja firma, a nie osoba korzystająca z Twojego kodu. Dlatego nie powinieneś przeciekać szczegółów swojego kodu do tego kodu innej firmy.

Nawiasem mówiąc, interfejsy i klasy są na końcu typami referencyjnymi. I to się liczy. Właśnie to musi podkreślić twoja konwencja nazewnictwa.

Większość odpowiedzi wydaje się zakładać, że językiem programowania jest Java lub C #, gdzie istnieje koncepcja (lub słowo kluczowe) dla interfejsów / klas abstrakcyjnych. W takich przypadkach, w przyzwoitym IDE, od razu widać, z jakim rodzajem klasy pierwszej zajmuje się, a pisanie public interface IMyClassjest niepotrzebnym powielaniem. To tak, jakbyś nie pisał public final FinalMyClass- wyobraź sobie umieszczenie każdego słowa kluczowego w nazwie klasy.

Jednak moim zdaniem w C ++ sytuacja jest nieco inna, ponieważ należy zagłębić się w plik nagłówka i sprawdzić, czy klasa ma jakieś wirtualne metody, aby dowiedzieć się, czy jest to klasa abstrakcyjna. W takim przypadku wyraźnie widzę argument za pisaniem class AbstractMyClass.

Tak więc moja odpowiedź brzmi: to zależy od języka programowania.

Zaktualizowany 2016: 2 lata doświadczenia w C ++ później prawdopodobnie uznałbym za niewłaściwą praktykę dodawanie nazw klas Abstract, chociaż powiedziałbym, że istnieją podstawy kodu, które są tak złożone, że może to mieć sens.

Postępuj zgodnie z idiomami używanego języka.

Każdy język ma swoje własne idiomy i wytyczne dotyczące kodowania. Na przykład w języku C # idiomatyczne jest używanie prefiksów z I. W Go nie jest.

W moim kodzie (Java) mam tę konwencję w interfejsach API, które udostępniam dzwoniącym:

• Funkcjonalność jest zapewniana przez interfejsy, a nigdy przez klasy.
• Części niefunkcjonalne to klasy.

Przez niefunkcjonalne rozumiem takie rzeczy jak czyste struktury danych (takie jak klasy, które działają jak pomosty do serializacji XML lub ORM), wyliczenia i wyjątki, z których wszystkie nie mogą być interfejsami (cóż, możesz to zrobić dla czystych klas danych , ale jest to dużo pracy przy niewielkim zysku, ponieważ klasy te nie robią nic oprócz przechowywania danych).

Jeśli chodzi o konwencje nazewnictwa, interfejsy mają tendencję do mapowania na rzeczowniki aktorskie (np. FooBarWatcher) Lub przymiotniki (np. FooBarWatchable), A zarówno czyste klasy danych, jak i wyliczenia mapowane na nieaktywne rzeczowniki (np. FooBarStatus); IDE może poprowadzić konsumenta interfejsu API bez specjalnych konwencji nazewnictwa. Wyjątki wykonaj zwykłe konwencje Java ( FooBarException, FooBarError, FooBarFault) Oczywiście.

Często również umieszczam interfejsy w ich własnych pakietach, a nawet we własnej bibliotece, aby upewnić się, że nie mam ochoty łamać własnych zasad. (Pomaga mi to również zarządzać kompilacją, gdy czerpię kod ze źródeł zewnętrznych, takich jak dokumenty WSDL).