Witam, mam problem ponieważ piszę program, który obsluguje logowanie userow o roznych uprawnieniach. Chciałem rozwiązać to w ten sposob, że mam klasę user i w zależności od uprawnień rozszerzam ją rożnymi dekoratorami zawierajacymi metody specyficzne dla danego typu usera.
Mam tylko problem, ponieważ tak utworzone obiekty będą miały różne typy w zależności jakie uprawnienia posiada dany użytkownik i ciężko potem taki obiekt przekazywać dalej.
Ma ktoś jakiś pomysł jak to rozwiązać lub jak lepiej zaimplementować obsluge uprawnień? Ostrzegam, że moja przygoda z C# i programowaniem obiektowym dopiero sie zaczyna.
Dzięki za każdą pomoc.
0
0
No chyba właśnie nie będą miały różnych typów jeżeli będziesz korzystał z dekoratora. Dekorator musi dziedziczyć po wspólnym interfejsie, więc to on będzie typem który będziesz przekazywał. Nie do końca tylko wiem czy użycie dekoratora to najlepszy pomysł. Prędzej użyłbym Strategii i za pomocą implementacji umożliwiałbym możliwości użytkownikom.
0
O strategii poczytam, bo nie udało mi się dojść do tego wzorca jeszcze, ale co do dekoratora chyba, nie za bardzo mogę użyć interfejsu jako typu, bo wtedy nie będą dostępne te dodatkowe metody, które zapewnia poszczególny dekorator, a tylko te które są określone w interfejsie.
1
No i własnie o to chodzi w polimorfizmie.
Jeżeli będziesz miał klasy User, Moderator, Admin i chcesz w tych samych miejscach wykorzystywać zamiennie obiekty tych klas to musza być połączone jakimś wspólnym interfejsem.
I teraz jeżeli twój Admin ma więcej publicznych funkcji niż User, to prędzej czy później będziesz musiał używać rzutowania aby się do nich dostać
Admin admin = (Admin)instanceUser;
wtedy ewentualnie sprawdzenie czy rzeczywiście instanceUser jest Adminem. Im więcej takich operacji tym bardziej możesz się upewnić, że twoje podejście do problemu jest złe. Dlatego interfejsy definiują jakąś wspólne postępowanie - wspólne = występuje wszędzie.
0
Ok, nie pomyślałem o rzutowaniu. Dzięki wielkie, spróbuję to zrobić w ten sposób. Jeśli rzeczywiście będzie to zbyt zawiłe to poszukam lepszego wzroca.
0
Jeśli masz "metody specyficzne dla danego typu", to to nie jest dekorator.
Potrzebujesz albo normalnej hierarchii obiektów, albo oddelegowania pewnej logiki do innych typów, zależy co chcesz finalnie osiągnąć.
0
Problem jest tego typu, przekazuję przez konstruktor takiego użytkownika do następnego okna np i trochę bez sensu jest mi pisać 3 konstruktory, sprawdzać za każdym razem, który użytkownik jest zalogowany, a jak chce przekazać to gdzieś dalej to wgl się robi jeszcze ciekawiej i zastanawiam się jak można to uprościć.
Przeszło mi dziś przez myśl, żeby spróbować użyć typów generycznych i każdy typ uprawnień opakowywać w Usera, ale musiałbym pomyśleć czy to rzeczywiście ułatwi mi sprawę.
0
A po co Ci w ogóle ten użytkownik w oknie? Bo wydaje mi się, że to jest źródło Twoich problemów.
0
Wydaje mi się, że klasa User i podtypy będzie się za bardzo rozrastać. Wydzieliłbym klasę Permission, która zawierałaby informacje o danej, konkretnej czynności. A potem ewentualnie jeszcze zebrał różne uprawnienia w Role.
0
Tworzę coś w rodzaju zaplecza magazynu i potrzebuję np. Admina, kogoś do zarządzania klientami i kogoś do zarządzania towarem. Jak już się zaloguję to w oknie do którego przekażę takiego Usera będą dostępne różne operacje w zależności od uprawnień. A metody typu AddUser, AddClient, NewOrder, przechowuję w klasach danego Usera.
2
Ok, czyli robisz odwrotnie niż cały świat, a Twoi Userzy łamią zasadę jednej odpowiedzialności, bo to tak naprawdę klasy robiące wszystko (czyli god objecty).
Wystarczy, aby Twój obiekt użytkownika miał możliwość w jakiś sposób zwrócić jego typ (w najprostszym przypadku właściwość typu bool IsAdmin, w najlepszym zwracając listę ról. Następnie kod odpowiedzialny za autoryzację sprawdza, czy dany użytkownik ma prawo do wykonania danej operacji. Zaś sam kod operacji powinien się znajdować w klasie odpowiedzialnej za wykonywanie operacji.