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

2

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

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