Bot aktualnie nie znajduje zastosowania ze względu na inny rodzaj captchy. Głównie zależy mi na ocenie struktury programu. Bardzo często korzystałem z statycznych metod i nie wiem, czy jest to dobre rozwiązanie (np. metoda addFriend
. Równie dobrze mogłaby być to niestatyczna metoda klasy account
.)
https://github.com/hamburgi/chomikuj-bot
0
1
Nazwy klas z małych liter i "_" aż w oczy razi
3
- +1 do tego, co pan wyżej. Nazewnictwo niezgodne z wytycznymi;
- Nie, metody statyczne w taki sposób, nie są dobrym rozwiązaniem;
- Nie masz odseparowania logiki i interfejsu użytkownika. Twoja klasa account, zawierająca same metody statyczne i tak musi korzystać z RestClienta, który tworzy się w formatce main. Dlaczego sama nie może się tym zajmować? Wtedy formatka nie musi nic wiedzieć o jakiejkowliek komunikacji;
- Powtarzasz ten sam kod. Możesz mieć jedną obsługę zdarzenia dla kilku elementów tego samego typu, bez problemu;
- Zrób sobie stałe do kolorów, a nie używaj magicznych liczb. Jak kiedyś przyjdzie zmienić kolor, to będziesz musiał zmieniać w wielu miejscach, a nie jednym;
-
Nie musisz porównywać wartości logicznych do true. Plus za użycie
string.IsNullOrWhiteSpace
!; - Legalną notkę? Ależ okropne tłumaczenie! ;-);
- Rozszerzenia do istniejących klas wydzieliłbym do osobnej klasy.;
- Znowu: lepiej innym klasom dawać, to, co mają wyświetlić, niż żeby one sobie same brały;
- O klasa email używa swojego RestClient, a mimo to... i tak wszystko jest statyczne!;
- Akurat klasa helpers może być statyczna, nic do tego nie mam - można się zastanowić, czy niektórych metod z tego nie przenieść jako metod rozszrzających do innych klas albo zmodyfikować klasy, aby były wewnątrz nich - np. getUserId dotyczy account, fetchToken też należy do komunikacji;
- Niektóre metody mają komentarze, a większosć nie. Ale ten akurat co podlinkowałem... to go nie rozumiem :-) - co to jest "directory enum" - numer katalogu, identyfikator katalogu? (i przy okazji znów nazewnictwo - nie używaj notacji węgierskiej);
- Fajne łapanie błędów - łapiesz, rozpoznajesz i ignorujesz w obu przypadkach ;-)
Nie, używanie metod statycznych w taki sposób, to nie jest dobry pomysł.
0
Ktos napisał(a):
- Fajne łapanie błędów - łapiesz, rozpoznajesz i ignorujesz w obu przypadkach ;-)
Plus zwracanie nulli z metod to tez kiepski pomysł. W tym przypadku lepiej zwrócić po prostu pustą listę.
Z reszta zwracanie z metod obiektów typu List<T> to osobny temat. Trzeba być świadomym tego, że jeśli ktoś inny (np. inny programista) będzie konsumował taką listę może do niej coś dodać lub usunąć - najczęściej nie jest to pożądane i znacznie lepiej zwrócić IEnumerable albo IReadOnlyCollection.