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ę.