Chciałbym stworzyć Użytkownika który inaczej zachowuje się z rolą **User **a inaczej z Admin. Mam zagwostkę czy stworzyć dwie oddzielne klasy dla User i dla Admin. User miałby przeglądać oferty pracy, składać na nie swoje cv. Administrator publikować te oferty oraz wysyłać newsletery itp.
Jak myślicie który podejście będzie lepsze takie w któym tworzę oddzielne klasy czy jedną z polem rola? Jeżeli jedną to jak podzielić metody dostępne dla jednej i drugiej roli?
Mogący czytać, mogący publikować, to dobre określenia dla interfejsu, gdyby była mowa o klasach **wykonujących ** aktywność (czy na Roli, jak się najszybciej wydaje, to nie jestem pewien *) )
BTW niemal zawsze się używa listy Ról, a nie "pole jedna Rola"
*) raczej funkcjonalność siedzi gdzie indziej., w serwisie / kontrolerze czy szeroko rozumianym backendzie
Odwrócę pytanie - dlaczego chciałbyś zrobić oddzielne klasy?
@Charles_Ray: Z powodu tego, że użytkownik miałbym również swój profil zawodowy, a administrator zarządzałby ofertami.
Ale ja pytam na poziomie kodu, dlaczego chcesz mieć 2 oddzielne klasy zamiast np. pola z rolami w jednej klasie?
@Charles_Ray: Bo w tej jednej klasie miałbym pole z obiektem profil zawodowy, który nie dotyczy użytkownika o roli admin.
Czy będąc Adminem mogę wykonywać akcję usera + admina, czy jest jakiś przełącznik, obowiązek przelogowania i user wtedy staję się userem bez admina?
@artur52: Admin nie wykonuje akcji usera. User jest kandydatem a Admin osobą która rozpatruje kandydata na podstawie jego profilu.
Uprawnienia != obiekt domenowy.
Zazwyczaj robi się tak że uprawnienia i dostępy przerzuca się na framework typu Spring Security. W kodzie aplikacji operuje się pojęciem roli w kontekście security. Czyli ktoś może być zalogowany do aplikacji i mieć role user, admin (bo może być i tym i tym). Inny może mieć role report_viewer.
Drugi przypadek typu profil usera to obiekt domenowy i nie powinien z autoryzacją mieć nic wspólnego może poza kluczem obcym do tabeli z użytkownikami z domeny security.