Konwencje nazewnictwa interfejsu Java [zamknięte]
Pracuję nad aplikacją webową Java, która używa Springa do wstrzykiwania zależności i JMocka do wyśmiewania się z tych zależności w naszych testach jednostkowych.
Obecnie nasz zespół jest w pewnym momencie, gdy mamy kilka różnych opinii na temat nazywania określonych interfejsów, których używamy. Nie mamy problemu z nazywaniem interfejsów w naszej domenie, które mają wiele implementacji, co jest proste. Jednak jeśli chodzi o interfejsy, dla których mamy tylko jedną implementację i zamierzamy mieć tylko jedną implementację w przyszłości, trafiliśmy na przeszkodę.
Powodem, dla którego mamy takie interfejsy, jest na przykład szyderstwo, mamy na przykład usługi i repozytoria, które wyszydzamy w naszych testach jednostkowych, a usługi te będą nazywane „DocumentMappingService” lub repozytoriami „EmployeeRepository”. W tej chwili niektórzy faceci po prostu poprzedzają skojarzoną nazwę interfejsu „I”, tj. „IDocumentMappingService” i „IEmployeeRepository”. Inni nazywają interfejs tak, jak powyżej, a następnie dodają „Impl” po nazwie interfejsu klasy implementacyjnej.
Trzecia „frakcja” uważa, że obie te opcje są słabe. Patrząc na literaturę, taką jak dobrze znane „oprogramowanie do wzrostu zorientowanego obiektowo, oparte na testach”, można by sądzić, że obie wspomniane wcześniej opcje są słabe i że nazwa interfejsu powinna jasno określać umowę i nazwę klas implementujących powinien jasno określać sposób realizacji tej umowy. Uznaliśmy to za dość trudne w przypadku, o którym wspomniałem powyżej.
Miałem nadzieję, że ktoś z nas miał wcześniej podobny problem i ma pewne sugestie, która opcja jest najlepsza i dlaczego. Ponadto, jeśli uważasz, że opcje „I” i „Impl” są słabe, to zasugeruj konkretną alternatywną konwencję.