Używanie "service" na końcu nazw klas serwisowych

1

Czy w nazwach klas serwisowych używacie sufiksu "service"? Np. TextLengthValidatorService czy po prostu TextLengthValidator? Co jest lepszą praktyką?

4

Ja nie używam, mam namespace'y i np takie coś "Services/Files/UploadHelper", więc importuje taką klasę i korzystam z niej jako UploadHelper. Moge ją sobie nazwać jako $uploadHelperService... ale mając podpowiedzi z IDE, ochodzę od tego typu nazewnictwa. Poza tym czasami zdarza się użyć np 3~5 parametrów i gdybym miał stosować sufiks, to wyglądałoby to tak
function doSomething(FileUploadService $fileUploadService, UploadHelperService $uploadHelperService, SomeSeriousShitService $someSeriousShitService)
Ja raczej preferuje krótsze nazwy. Oczywiście trzymam się standardów i przyjętych konwencji (ogólnie/per projekt). Dlatego wolę robić to tak

use Services\FileUpload;
use Services\UploadHelper ;
use Services\SomeSeriousShit ;

function doSomething(FileUpload $fileUpload, UploadHelper $uploadHelper, SomeSeriousShit $someSeriousShit)

Także porównaj sobie
function doSomething(FileUploadService $fileUploadService, UploadHelperService $uploadHelperService, SomeSeriousShitService $someSeriousShitService)
vs
function doSomething(FileUpload $fileUpload, UploadHelper $uploadHelper, SomeSeriousShit $someSeriousShit)

W IDE od razu wiem co jest co i tyle. No chyba, że Twój język nie pozwala na silniejsze typowanie - to wtedy bym dodawał sufiksy.
Kiedyś istniała np notacja węgierska - co stosowałem w phpie, więc miałem zmienne $iSomeNumber -> gdzie pierwsza literka oznaczała typ zmiennej. Świat (w tym php) poszedł do przodu i możemy określać typy zmiennych, więc i ta notacja poszła w niepamięć.

5
Edelner napisał(a):

Czy w nazwach klas serwisowych używacie sufiksu "service"?

Jeśli klasa jest serwisem to tak.

Np. TextLengthValidatorService czy po prostu TextLengthValidator?

Akurat słaby przykład, bo niby dlaczego walidator ma być serwisem? Serwis to serwis, a walidator to walidator i nie rozumiem dlaczego miałby mieć sufiks Service. Jeśli już jakimś cudem miałby być serwis obsługujący walidację (choć nie za bardzo rozumiem po co) to bardziej TextLengthValidationService.

0

A kiedy klasa jest serwisem?

0

Dla mnie klasa jest serwisem, kiedy znajduje się w warstwie aplikacji i jest pomostem pomiędzy warstwą domeny (logiki), a warstwą infrastruktury. Na przykład UsersService zawierająca operacje na użytkownikach albo OrdersService do zarządzania zamówieniami. Choć pewnie ktoś zna lepszą definicję.

9

A kiedy klasa jest serwisem?

Wtedy, gdy nie jest managerem. ;)

Ogólnie service (tak jak i manager) brzmi jak brak pomysłu na lepszą nazwę, co może być powodowane tym, że klasa ma jednak zbyt wiele odpowiedzialności. Jeśli klasa robi tylko jedną rzecz, to łatwiej ją nazwać.

1

Pytanie jest trudne bo to tylko konwencja a konwencje różnią się między językami a nawet frameworkami.
Np w Javie/Springu wypracowano konwencje że logika biznesowa jest w Service'ach. Walidator to nie logika biznesowa. Walidatory są często używane przed wejściem do właściwej logiki biznesowej. No chyba że piszemy moduł/mikroservice którego logiką biznesową jest konfigurowalna walidacja. Albo wynik walidacji jest zmienny w czasie i zależy od bazy danych. Wtedy taki walidator nie jest prostym utilem/helperem tylko raczej serwisem

3

A kiedy klasa jest serwisem?

Dosyć często kiedy udajemy że stosujemy OOP i zamiast tego robimy programowanie proceduralne (tylko z użyciem jakiś kontenerów IoC)

Walidator to nie logika biznesowa.

A sprawdzenie czy pesel jest poprawny to jest już logika biznesowa czy nie?

Jeśli klasa robi tylko jedną rzecz, to łatwiej ją nazwać.

Np. SendTransferUserCase. A tak poza tym to w sumie lepiej używac prawdziwych obiektów domenowych (nie mylić z encjami JPA)

0
Aleksander32 napisał(a):

A sprawdzenie czy pesel jest poprawny to jest już logika biznesowa czy nie?

A co rozumiesz przez prawdzenie?

  • \d{11} + sprawdzenie cyfry kontrolnej - Walidator/util
  • Strzał do zewnętrznego systemu żeby spradzić czy to PESEL jakiejkolwiek osoby (żywej lub martwej) - jest to klient (może dao)
1
KamilAdam napisał(a):
Aleksander32 napisał(a):

A sprawdzenie czy pesel jest poprawny to jest już logika biznesowa czy nie?

A co rozumiesz przez prawdzenie?

  • \d{11} + sprawdzenie cyfry kontrolnej - Walidator/util
  • Strzał do zewnętrznego systemu żeby spradzić czy to PESEL jakiejkolwiek osoby (żywej lub martwej) - jest to klient (może dao)

A jak mam dwie implementacje takiego komponentu, gdzie jedna robi pierwszą logikę, a druga robi drugą, to jak według Ciebie powienien nazywać się kontrakt obejmujący obie implementacje (np. interfejs w javie)?

Aleksander32 napisał(a):

A kiedy klasa jest serwisem?

Dosyć często kiedy udajemy że stosujemy OOP i zamiast tego robimy programowanie proceduralne (tylko z użyciem jakiś kontenerów IoC)

Co jest złego w programowaniu proceduralnym? Kolejne korpo-crudy przecież nie potrzebują DDD

0
Tyvrel napisał(a):
KamilAdam napisał(a):
Aleksander32 napisał(a):

A sprawdzenie czy pesel jest poprawny to jest już logika biznesowa czy nie?

A co rozumiesz przez prawdzenie?

  • \d{11} + sprawdzenie cyfry kontrolnej - Walidator/util
  • Strzał do zewnętrznego systemu żeby spradzić czy to PESEL jakiejkolwiek osoby (żywej lub martwej) - jest to klient (może dao)

A jak mam dwie implementacje takiego komponentu, gdzie jedna robi pierwszą logikę, a druga robi drugą, to jak według Ciebie powienien nazywać się kontrakt obejmujący obie implementacje (np. interfejs w javie)?

Bardziej zasobożerny przypadek zwycięża. Tylko nazwałbym to coś w rodzaju RealPeselValidationService i DummyPeselValidationService

Co jest złego w programowaniu proceduralnym? Kolejne korpo-crudy przecież nie potrzebują DDD

IHMO programowanie proceduralne ma zalety. Łatwiej przerobić je na FP niż DDD przerobić na FP :P

3
Tyvrel napisał(a):

A jak mam dwie implementacje takiego komponentu, gdzie jedna robi pierwszą logikę, a druga robi drugą, to jak według Ciebie powienien nazywać się kontrakt obejmujący obie implementacje (np. interfejs w javie)?

Dlaczego chcesz mieć wspólny interfejs do rzeczy leżących na różnych poziomach abstrakcji? Przecież walidacja peselu oraz sprawdzanie czy człowiek o danym peselu istnieje, to dwie różne rzeczy, używane w dwóch różnych miejscach aplikacji, i zapewne zwracające różne typy wyników.

1
somekind napisał(a):
Tyvrel napisał(a):

A jak mam dwie implementacje takiego komponentu, gdzie jedna robi pierwszą logikę, a druga robi drugą, to jak według Ciebie powienien nazywać się kontrakt obejmujący obie implementacje (np. interfejs w javie)?

Dlaczego chcesz mieć wspólny interfejs do rzeczy leżących na różnych poziomach abstrakcji? Przecież walidacja peselu oraz sprawdzanie czy człowiek o danym peselu istnieje, to dwie różne rzeczy, używane w dwóch różnych miejscach aplikacji, i zapewne zwracające różne typy wyników.

Co gorsza, istnieją ludzie z niepoprawnym peselem -- i co im zrobisz?

0
Edelner napisał(a):

Czy w nazwach klas serwisowych używacie sufiksu "service"? Np. TextLengthValidatorService czy po prostu TextLengthValidator? Co jest lepszą praktyką?

w JS bym napisał po prostu funkcję validateTextLength, a nie bawił się w klasy i nazewnictwo jak w niemieckich rzeczownikach. Ale co język, to obyczaj.

0

Service nic nie mówi o tym co ta klasa robi. Na code review od razu piszę, że to błąd i do poprawy.

2

A jak mam dwie implementacje takiego komponentu, gdzie jedna robi pierwszą logikę, a druga robi drugą, to jak według Ciebie powienien nazywać się kontrakt obejmujący obie implementacje (np. interfejs w javie)?

Tak jak @somekind napisał. Dodam że jeszcze była bardzo ciekawa dyskusja na temat pierwszej logiki:
Value objecty - walidacja

Co jest złego w programowaniu proceduralnym?

Nic, tylko nie wiem po co mówić że się pisze że się obiektowo jak pisze się proceduralnie. Jak masz na przykład serwis (aplikacje) do odbierania wiadomości z kafki i puszczania emaili w której po prostu przerzucasz Stringi z lewej na prawą to wtedy takie coś ma sens. Jak masz już jakiś bardziej złożony biznes lodżik to mniej.

Kolejne korpo-crudy przecież nie potrzebują DDD

A gdzie ja pisałem o DDD?

1 użytkowników online, w tym zalogowanych: 0, gości: 1