Aktywne Wpisy
Moreso_pl +696
Zapraszamy na #rozdajo z Moreso.pl
Do wygrania jest paczka o wartości 85 zł, która składa się z:
1. masło orzechowe 1 kg
2. orzeszki w chrupiącej skorupce o smaku zielona cebulka 700g
3. mango suszone 500g
4. orzeszki ziemne chili&lime 1 kg
Zasady:
1. Zaplusuj ten wpis
2. Odpowiedz na pytanie:
Osoba z komentarzem o największej ilości plusów wygrywa. Ciekawi jesteśmy Waszej kreatywności ( ͡° ͜ʖ ͡°)
Dodatkowo
Do wygrania jest paczka o wartości 85 zł, która składa się z:
1. masło orzechowe 1 kg
2. orzeszki w chrupiącej skorupce o smaku zielona cebulka 700g
3. mango suszone 500g
4. orzeszki ziemne chili&lime 1 kg
Zasady:
1. Zaplusuj ten wpis
2. Odpowiedz na pytanie:
Osoba z komentarzem o największej ilości plusów wygrywa. Ciekawi jesteśmy Waszej kreatywności ( ͡° ͜ʖ ͡°)
Dodatkowo
1-1-1-1 +282
Ma ktoś pomysł jak przetestować wyrzucanie tego wyjątku?
AirborneStatus ma 2 pola, jedno jest stringiem a drugie booleanem, nie ma opcji żeby podać złe dane - o ile nie ma błędu w oprogramowaniu, wiadomość zawsze utworzy się dobra, a wtedy też dobrze się zaszyfruje do XMLa...
Chciałabym uniknąć używania PowerMocka (obie metody są statyczne, klasy Utils...), bo słyszałam że to świadczy o złym designie... W takim razie jak przeształcić ten kod żeby był dobry i testowalny?
Myślę nad tym i myślę i nie wiem jak to wymyślić ( ͡° ͜ʖ ͡°)
@noelo_cohelo: Nie powinno to stanowić problemu, bo:
* powinnaś preferować kompozycję wobec dziedziczenia: https://en.wikipedia.org/wiki/Composition_over_inheritance => czyli jak przekombinowałaś z dziedziczeniem i utrudnia Ci to działania, to raczej należy tutaj zacząć fixowanie dizajnu
* konstruktor można nadpisać => parentowi przekazujesz co potrzebuje, sobie przypisujesz co Ty potrzebujesz
* jak konstruowanie obiektu robi się skomplikowane,
@noelo_cohelo: tak, ma to na celu "poprawienie" testowalności. Poprawienie dałem w cudzysłów, ponieważ jest to bardzo brzydki workaround. Niestety czasami trzeba robić takie rzeczy, gdy korzystamy z mechanizmów zewnętrznych.
Generalnie podpisuję się rękami i nogami pod tym co napisał @MacDada. Od siebie mogę polecić przestudiowanie podejścia TDD - po pewnym czasie, nawet nie zauważysz kiedy, podświadomie
@noelo_cohelo: Nie robię w Javie: co ten cały
JAXBException
reprezentuje? Kiedy wyskakuje? Załóżmy, żecreateFlightStatusMessage
nie waliduje jakośmessage
=> jak powinnomessage
wyglądać, żebyJAXBException
wyskoczyło?Swoją drogą tutaj znów wychodzi, że static statica pogania ;p Bo przecież
FlightObjectUtils
też nie masz jak podmienić ;)Generalnie jak masz zamiar użyć słowa
util
w nazwie klasy, to raczej@nfan: Nie robię w Javie. Osobiście unikam statyka jak ognia. Zresztą, w PHP mamy standard PSR-3, który definiuje
LoggerInterface
=> czyli właśnie standardem jest przyjmować obiekt w konstruktorze (który implementuje ten interface), a nie jakieś latanie statykami.Statyki to rak sprzed 15–u lat => z dzisiejszą wiedzą (SOLID) i narzędziami (kontenerki zależności) nie ma powodu, żeby dalej akceptować
SpringLogger.getInstance().log('blah');
to bym wyodrębnił moją własną abstrakcję i ją wstrzykiwał:interface Logger
{
public void log(String message);
}
class SpringLoggerAdapter implements Logger
{
public void log(String message)
{
SpringLogger.getInstance().log(message);
}
}
class MyLoggerConsumer
{
public void MyLoggerConsumer(Logger logger);
}
Zresztą, to dobra praktyka, bo robisz cieniutką warstewkę, a uniezależniasz się od frameworka (możesz podmienić sposób logowania w przyszłości