Postawa paranoiczna objawia się szczególną wrażliwością na oszustwa i krętactwo. W myśl zasady skoro ja kombinuję to oni też. Na dłuższą metę taka postawa powoduje tylko spadek wzajemnego zaufania wśród ludzi, zaufania do firm i państwa.
Istnieją jednak pozytywne aspekty takiego stanu. Polacy są w czołówce swoistych “security nazi”. Zwracają uwagę na bezpieczeństwo swoje i swojej rodziny, nie ulegają podszeptom speców od PRu (inaczej – mają wyższy próg odporności na reklamę) oraz potrafią wywęszyć próby oszustwa. Do tego dochodzi talent do wymyślania “metod obejścia systemu”. Czasami robią to aż za nadto skutecznie.

Dzisiejszy hit to system płatności elektronicznej Sofort. Pisze o tym i niebezpiecznik i blogerzy jednego posta (sorry za nazwę, ale to jest naprawdę pierwszy post na tym blogu, pomijając zwyczajowe “o czym blog”). Generalnie problem polega na tym, że firma prosi klienta o podanie loginu, hasła i hasła jednorazowego z SMSa w celu dokonania płatności. Za pomocą tych danych loguje się na konto (Selenium willkomen) i wykonuje przelew.

System działa z powodzeniem w wielu krajach i nie było chyba jakiejś większej wpadki. W Polsce – Kraju Ludzi Uczciwych Inaczej pierwszą rzeczą było wykombinowanie “jak okraść”, a następnie piętnowanie “korzystających idiotów”. Choć system nie jest doskonały to jednak nigdzie na świecie nie spotkałby się z taką reakcją. Takie podejście świadczy tylko o poziomie wzajemnego zaufania pomiędzy Polakami. Bez poprawy tego poziomu nie ma co marzyć o normalnym państwie.

Dodaj do

Przekopując się przez wujka Google’a trafiłem na bardzo ciekawe repozytorium schematów. Niestety nie udostępnia ono gotowych DDLi i skryptów wypełniających. Szkoda. Generalnie trzeba trochę poklikać i popisać by uzyskać jakiś rozsądny schemat.

A może wy znacie jakieś gotowe schematy, które można wykorzystać do szkoleń?

Dodaj do

Synchroniczność i asynchroniczność

Mając pewną długą operację zazwyczaj musimy zdecydować czy ma być ona wykonana synchronicznie czy asynchronicznie. Oba podejścia są dobre. Wybór zależy zatem od konkretnego przypadku. Ogólnie jeżeli nie mamy jakiś obostrzeń to wybór metody asynchronicznej jest co do zasady odpowiedni. Metoda synchroniczna powinna zostać wybrana jeżeli w trakcie trwania danej operacji inne działania mogą wpłynąć na jej wynik. Względnie w przypadku aplikacji webowych jeżeli kolejne żądania mogą spowodować nieprawidłowe działanie aplikacji.
Przykładowo dobrym miejscem na wykonanie akcji synchronicznej jest zdalna aktualizacja sterowników routera albo definicji raportu Jasper Reports. Czyli tam gdzie nie będziemy wstanie zagwarantować iż żądanie wysłane w trakcie operacji skończy się sukcesem.

Ten sam JVM czy inny

Jest to znacznie ciekawszy problem. Generalnie wszystko zależy od tego czy nasza operacja może doprowadzić do sytuacji w której JVM nie będzie mógł kontynuować pracy. Takich przypadków jest kilka.

Brak pamięci

Coraz rzadsza przypadłość. W czasach Javy 32bitowej i limitu niecałych 2GB na proces opłacało się wyrzucić ciężkie i pamięciożerne zadania do osobnego JVM. W razie wystąpienia wyjątku główny proces był nienaruszony. Dziś brak RAM dla JVM nie jest już problemem. Jak trzeba to się instaluje. Jak mało to się odpala coherence i współdzieli RAM pomiędzy maszynami.

Przepełnienie stosu wywołań i nieskończone pętle

W ogólności sytuacje gdzie zadanie idzie w przysłowiowe maliny. W takim wypadku siłowe ubicie procesu za pomocą SIGKILL jest zdecydowanie łatwiejsze niż próby ubicia wątku na działającym serwerze.

Nadużywanie GC w czasie działania

Sytuacja w której po zakończeniu pracy uruchamiany jest GC i radośnie sprząta… minutę, dwie… albo i więcej. Czasami tak bywa. Niestety uruchomienie GC może zablokować serwer… a to boli.

Synchroniczność wywołania zewnętrznego JVM

Mówiąc po polsku oczekiwanie na zakończenie uruchomionego procesu JVM. Zasady takie jak wymieniłem wyżej. Z tą różnicą, że opłaca się to robić tylko przy małej ilości użytkowników ponieważ osoby, które wyślą żądanie w trakcie działania procesu, ale nie wiedzą o jego uruchomieniu nie powinny spotykać się zbyt często z komunikatem w stylu “przerwa konserwacyjna”.

Dodaj do

Który listener lepszy

Oba są dobrym rozwiązaniem. Wybór powinien nastąpić w wyniku analizy polegającej na odpowiedzi na pytanie:

Kto powinien decydować o tym, że dane zdarzenie zakończyło się sukcesem albo porażką?

Jeżeli decyzję powinien podjąć klient to lepszym jest listener z listingu 1. Jeżeli to my decydujemy to oczywiście rozwiązanie z listingu 2.
Istnieją jednak dwa wyjątki. Pierwszy to duże zróżnicowanie protokołów (zdarzeń powodujących wywołanie listenera) w tym przypadku lepszym rozwiązaniem jest druga wersja listenera. Działa ona wtedy jak adapter. Jeżeli jednak protokół jest jeden i jest dobrze zdefiniowany to pierwszy z listenerów jest wystarczający. Jego użycie upraszcza nasz kod.
Drugi wyjątek to sytuacja w której nie interesuje nas treść zdarzenia, ale tylko fakt jego zaistnienia. Jest to typowa sytuacja dla listenerów o których mówił Daniel w swoim komentarzu – loggerów, ale też np. listenerów audytowych czy listenerów związanych z bezpieczeństwem.

Zagadka właściwa

Dzisiejsza zagadka jest trochę trudniejsza. Mamy do wykonania pewne długotrwale zadanie. Wiemy, że będzie ono wykonywało się bardzo długo w stosunku do oczekiwań użytkownika. Pytanie brzmi:

Poniższa lista zawiera kilka modeli wykonania zadania. Czym będziesz kierować się przy wyborze konkretnego modelu?

• Wywołanie synchroniczne EBJ albo usługi działającej w ramach tego samego procesu JVM wraz ze zmianą konfiguracji aplikacji webowej tak by nie groził błąd HTTP 408 request timeout.
• Wywołanie synchroniczne usługi działającej w ramach innego procesu JVM.
• Wywołanie asynchroniczne EJB albo usługi działającej w ramach tego samego procesu JVM.
• Wywołanie asynchroniczne usługi działającej w ramach innego procesu JVM.

Od razu mówię, ze wszystkie punkty mają sens. Twoim zadaniem jest wskazanie przykładowych sytuacji, w których zastosowanie poszczególnych rozwiązań jest najlepsze.

Dodaj do

Przykładowo tradycyjna aplikacja wykorzystująca formularze CUD (Create, Uprade, Delete) ma zazwyczaj podpięty jeden obiekt DAO, który realizuje poszczególne operacje. Co jednak gdy chcemy informować różne usługi o zmianach zachodzących w obiekcie? Chociażby zapisywać logi do celów audytowych czy statystycznych? Oczywiście można wprowadzać zmiany. Ba! Można do tego użyć programowania aspektowego i wstawiać aspekty w runtime… można… można też od początku stosować kolekcje usług i później dodawać/usuwać pojedyncze elementy.

Jednak nie o tym chciałem, choć temat ciekawy.

Mamy sobie do zaimplementowania listener dla pewnej usługi. Wywołanie usługi może zakończyć się na dwa sposoby sukcesem albo porażką (LOL odkrywcze). Teraz zagadka.

Na poniższych listingach przedstawiono dwa interfejsy listenera pewnej usługi. Pytanie brzmi, który z nich jest lepszym rozwiązaniem i w jakiej sytuacji:

Listing 1. Listener “jednometodowy”

interface ServiceListener{
    public void onEvent(Event e);
}

Klasa Event zawiera odpowiedź usługi w czystej postaci (strumień, String, prymityw).

Listing 2. Listener “wielemetodowy”

interface ServiceListener{
    public void onSuccess(Response r);

    public void onError(Error e);
}

Klasy Response i Error zawierają odpowiedź w czystej postaci, ale są wstępnie filtrowane tak by rozróżnić sukcesy i porażki.

Dodaj do

Generalnie współczesne obfuskatory potrafią robić kilka rzeczy poza samym zaciemnianiem nazw. Te są przydatne:

• Usuwanie nieużywanego kodu.
• Usuwanie informacji dla debuggera.
• Upraszczanie niektórych wyrażeń (shriking).
• Optymalizacja kodu m.n. wykorzystania zmiennych lokalnych.

W efekcie możemy dostać kod mniejszy i trochę wydajniejszy, ale będziemy musieli za to zapłacić bardzo wysoką cenę. Jest nią możliwość utrzymania kodu. Skoro kod wyjściowy zostanie potraktowany refaktoryzacją Zmiana nazwy to w efekcie gdy otrzymany od klienta stacktrace stanie się ciekawą łamigłówką pt. “Co to za klasa się wyjebała”.
Kolejną wadą jest utrata możliwości powtórnego użycia kodu. Obfuskowany jar, który zawiera zestaw metod narzędziowych… a ty siedzisz i piszesz wszytko od nowa
Na koniec należy też dodać utratę powiązania pomiędzy kodem, a dokumentacją. Wdrożenie nowego człowieka w projekt będzie bolesne… szczególnie jak mu się trafi obfuskowany stacktrace.

Zalety? Tak są. Obfuskatorów należy używać jeżeli piszemy na platformę JME albo Java Card i mamy ograniczenia co do ilości wyprodukowanego kodu. W takim wypadku warto użyć obfuskatora. Kolejną jest użycie obfuskatora z wyłączonym modułem zmiany nazw w celu optymalizacji kodu. Zazwyczaj jest to upraszczanie wyrażeń (np. dodawania Stringów) lepsze wykorzystanie zmiennych lokalnych, usuwanie informacji dla debuggera czy martwego kodu. Czasami niewielkie zyski w tym zakresie są jak najbardziej pożądane. Przykładowo jeżeli uda nam się zmniejszyć wielkość paczki pobieranej przez klienta o 10% to dla 100MB jara wynik 10MB mniej na pobranie jest już znaczący zarówno dla naszych dysków jak i łączy.

Ale najważniejsze. Nie używajcie obfiskatorów. Najlepiej nigdy.

Dodaj do

Jak wiadomo w Javie zarezerwowano słowo goto, ale nie jest ono zaimplementowane. Kwestią sporną pozostaje czy ta instrukcja jest sensowna w języku obiektowym czy też nie. W zamian za nią pedrowaty wskazał, że nadal można używać instrukcji break i continue. Co więcej powiem wam, że można tych instrukcji używać w taki sam sposób jak używano słowa kluczowego goto.

Listing 1. użycie break jak goto

public class SimpleGoTo {
	public static void main(String[] args) {
		int i = 0;
		int j = 0;

		REPEAT: {
			while (i < 10) {
				i++;
				System.out.println(i + "/" + j);
				if (j > 5) {
					break REPEAT;
				}
				j++;
			}
			System.out.println(i + "///" + j);
		}
	}
}

Jak się pobawicie to dojdziecie do wniosku, że można używać namiastki goto w postaci break LABEL. To był przykład z pętlą teraz trochę bardziej mieszający w głowie, czyli break LABEL z ifem:

Listing 2. użycie break z if

public class SimpleGoTo {
	public static void main(String[] args) {
		int i = 0;
		int j = 0;
		REPEAT: {
			MAGIC: {
				while (i < 10) {
					i++;
					System.out.println(i + "/" + j);
					if (j > 5) {
						break MAGIC;
					}
					j++;
				}
			}
			if (i + j > 10){
				break REPEAT;
			}
			System.out.println(i + "///" + j);
		}
	}
}

Zatem można stwierdzić, że dopóki pozostajemy w danym zakresie (bloku kodu ograniczonym { i }) to możemy używać namiastki goto. Do czego można tego użyć?

W swojej karierze spotkałem się tylko raz z użyciem takiej konstrukcji. Mianowicie w ten sposób można kontrolować przepływ sterowania w programie jeżeli migrujemy z kodu pre-strukturalnego. Dzięki temu można w miarę łatwo przenieść zasadę działania oryginalnego programu, a dopiero później zastosować refaktoryzacje mające na celu zmianę struktury kodu.

Tergo typu konstrukcji nie stosujemy w nowo utworzonym kodzie. Dlaczego? Ponieważ jak ostatni raz tego użyli to meteoryt walnął w Ziemię i powstała nauka zwana Paleontologią. A na serio… trudność utrzymania takiego kodu jest bardzo duża. Wprowadzanie zmian ciężkie, a awaryjność wysoka. Poza tym taki kod nie ma sensu w przypadku programowania obiektowego.

idę spać.

Dodaj do

Postaram się przez najbliższych kilka dni przygotować i udostępnić archetyp zawierający:

• Vaadin
• JSR-303
• JPA2
• Shiro
• Guice

Całość przetestowana za pomocą testng.

Dodaj do

Poglądowo

W spotkaniu chodziło o przedstawienie osobom odpowiedzialnym za USOS pewnego stosu technologicznego, na którym należało by oprzeć nowy moduł systemu.

Czym jest USOS?

USOS jest to mówiąc w dużym skrócie mieszanka ERP^W i CRM^W oraz narzędzi specyficznych dla zarządzania uczelnią. Składa się on z kilku modułów. Na konferencji skupiliśmy się na trzech z nich USOS, USOS-web i USOS-UL.
Pierwszy to “USOS właściwy”, czyli baza danych wraz z interfejsem biznesowym do zarządzania uczelnią. Całość postawiona na Oracle + Oracle Forms. Duże to jak cholera (ponad 300 formularzy) i coraz trudniejsze w utrzymaniu.
Drugi to interfejs web, przez który studenci mogą sobie zobaczyć np. plan zajęć czy pobrać materiały. Tu króluje php i mysql. Z głównym systemem integracja polega na cyklicznej synchronizacji baz danych. Oznacza to, że USOS-web może nie mieć aktualnych danych. Podobnie danych może nie mieć USOS główny.
Trzeci element to moduł na który klną wszyscy studenci. Jest on odpowiedzialny za rejestrację na lektoraty i WF. Dwa razy do roku mamy tu DDoS

Pomysły

Generalnie idea jest taka by napisać wszystko z wykorzystaniem Springa i jego modułów do biznesu, a GWT/Vaadin/JS jako warstwy widoku. W ogólnym ujęciu serwer aplikacji wystawiał by zestaw usług opartych o REST oraz pozwalał na ich uruchamianie via aplikacja web.
W toku dyskusji został podniesiony problem aplikacja web kontra aplikacja desktopowa. Jednak Jacek Laskowski elegancko spacyfikował towarzystwo stwierdzając, że każda aplikacja oparta o wołanie usług po http to aplikacja web. Zgadzam się z nim w pełni, a jedyne co można tu dodać to rozróżnienie na klienta www i klienta desktopowego.

Debata

Generalnie przyszło nam zmierzyć się z dość trudnym tematem… interfejsu użyszkodnika. Większość czasu poświęciliśmy na próby odpowiedzenia czy UI ma być w GWT czy w Vaadin. Moim zdaniem była to ciekawa, ale nie wnosząca nic do tematu pogawędka. Niepokoi mnie to, że praktycznie nie poruszono tematów związanych z backendem. Przyjęto, że używamy Springa i koniec. Wtrącenie na temat EJB zostało ucięte już na samym początku. Szkoda.

Moja propozycja

Podsumowując całość mam taką propozycję.

Po pierwsze skupić się na napisaniu dobrego backendu. Wykorzystać do tego Springa i to nie ze względu na kontener IoC, ale ze względu na dużą ilość modułów pozwalających na integrację z potrzebnymi nam technologiami. Beany springowe powinny być dostępne tylko i wyłącznie jako usługi oparte o REST. Całość należy wdrożyć na TomEE, czyli specjalnej wersji Tomcata, która jest zgodna z webprofilem JEE6. Dlaczego tak? Ponieważ z jednej strony mamy lekkiego Tomcata, który w zupełności wystarczy do uruchomienia aplikacji w Springu. Ma on też możliwość clustrowania, a że całość będzie bezstanowym wołaniem usług to można będzie w razie konieczności zestawić cluster dynamicznie dostosowujący swoją wielkość do obciążenia. Z drugiej strony TomEE posiada wszystko co powinien mieć typowy serwer aplikacji zatem jeżeli będziemy chcieli uruchomić na nim jakieś usługi EE to też nie będzie problemu. Tu ważna rzeczy. Obecnie trwają już prace nad przejściem z Oracle Reports na BIRT.
Jak wspomniałem Springa wybieramy ze względu na moduły. Kontener IoC jest tu drugorzędnym problemem i jeżeli miałbym się kierować tylko i wyłącznie nim jako kryterium wyboru to bym wybrał Guice. Jest prostsze. Tu interesują nas moduły

• Security – wiadomo
• CXF integration- czyli obsługa webservice po REST z wykorzystaniem Apache CXF.
• batch – narzędzia do przetwarzania wsadowego.
• Dynamic modules – jako platformę OSGi

Co dalej… Jacek rzucił pięknym tekstem:

Aplikacja webowa jako referencyjna implementacja klienta REST

Zgodnie z tym podejściem inny zespół powinien otrzymać API aplikacji USOS i rozpocząć deweloperkę klienta web opartego o wołanie usług. Aplikacja web oraz główna aplikacja powinny zostać całkowicie od siebie odseparowane. Ma to dwa duże plusy. Po pierwsze pozwala wyrzucić poza core-aplikację wszystko co związane z obsługą sesji HTTP. Dzięki temu upraszczamy znacząco implementację. Po drugie aplikacja ma spójny interfejs REST-only dzięki czemu deweloperzy nie muszą martwić się “czy ruszy na kliencie”. Po prostu wystawiają usługę z jasno zdefiniowanym interfejsem. Samą aplikację web napisałbym z zwykorzystaniem Vaadin ponieważ jest to proste i łatwe w użyciu narzędzie.

Na dokładkę dodałbym trochę dupereli typu zbudowanie środowiska deweloperskiego wykorzystującego serwer CI, raportowanie jakości kodu, jakieś automatyczne wyszukiwanie problemów. Zarówno statycznych (findbug) jak i dynamiczne (patrz praca Patrycji Wegrzynowicz). Pewno coś jeszcze by się znalazło.

Nie poruszam tu problemu bazy danych, ponieważ na chwilę obecną i tak system musi korzystać z już istniejącej bazy, a w przyszłości może wydarzyć się jeszcze wiele różnych rzeczy, które mogą wpłynąć na wybór w tym zakresie.

Dodaj do

Mamy sobie pewien model danych, a w nim klasę SomeClass:

Listing 1. Klasa SomeClass

public class SomeClass {

	@NotNull
	private final Integer someInt;

	public SomeClass(Integer someInt) {
		this.someInt = someInt;
	}

	public Integer getSomeInt() {
		return someInt;
	}

}

Ma ona jedno pole, które niesie ze sobą jakąś tam informację biznesową. Bez wnikania w szczegóły pole nie może być null. Możemy zatem założyć, że taki test:

Listing 2. Test SomeClass

public class SomeClassTest {

	private Validator validator;

	@BeforeClass
	protected void setUp() {
		validator = Validation.buildDefaultValidatorFactory().getValidator();
	}

	@Test
	public void simpleValidationForClass() {
		assertThat(validator.validate(new SomeClass(1))).isEmpty();
		assertThat(validator.validate(new SomeClass(null))).isNotEmpty();
	}

}

Jest ok.

W toku prac nad kodem dochodzimy do miejsca, w którym musimy wprowadzić nową podklasę klasy SomeClass, która zachowuje się tak samo, ale jej pole może przyjmować tylko wartość null. Musimy zatem przesłonić pole albo metodę w klasie SubSomeClass. Ja wybrałem bardziej intuicyjny element – pole.

Listing 3. Klasa SubSomeClass

public class SubSomeClass extends SomeClass {

	@Null
	private final Integer someInt;

	public SubSomeClass(Integer someInt) {
		super(someInt);
		this.someInt = someInt;
	}

	@Override
	public Integer getSomeInt() {
		return someInt;
	}
}

Test, który powinien przejść w takim wypadku wygląda tak:

Listing 4. Test SubSomeClass

public class SubSomeClassTest {
	private Validator validator;

	@BeforeClass
	protected void setUp() {
		validator = Validation.buildDefaultValidatorFactory().getValidator();
	}

	@Test
	public void simpleValidationForSubClass() {
		assertThat(validator.validate(new SubSomeClass(null))).isEmpty();
		assertThat(validator.validate(new SubSomeClass(1))).isNotEmpty();
	}
}

… jednak z pewnego powodu test nie przechodzi.

JSR-303 u notariusza

Dziedziczenie jak wiadomo jest najlepszą, obiektową metodą na wzbogacenie się. Dziedzicząc jednak z klasy robimy to w prost co oznacza, że wzbogacamy się o wszystkie elementy klasy z której dziedziczymy jak i odpowiadamy za wszelkie długi (technologiczne), które dana klasa zaciągnęła. Tak to wygląda w przypadku klas.
JSR-303 ma tu jednak pewne pole do manewru ponieważ posługując się refleksją może spróbować innych sposobów zarządzania technologicznym “spadkiem”.

• Może odrzucić spadek w całości o nie ma sensu ponieważ nie będzie wtedy weryfikował nieprzesłoniętych pól nadklasy.
• Może przyjąć spadek “z dobrodziejstwem inwentarza”, czyli w przypadku gdy w nadklasie jest już pole o takiej samej nazwie to nie uruchamia jego walidacji.

Niestety twórcy specyfikacji poszli po linii najmniejszego oporu delegując zachowanie do “zasad widoczności w specyfikacji języka”. Efekt możecie podziwiać wyżej.

Jak sobie z tym poradzić?

Najprościej jest wnieść walidację na poziom całej klasy poprzez własny walidator, ale na dłuższą metę to też nie zadziała. W Walidatorze i tak będziemy musieli sprawdzać typ obiektu. Drugą metodą jest rozbudowa hierarchii w taki sposób by klasa SomeClass stała się klasą abstrakcyjną, a pola umieścić w klasach z niej dziedziczących. Już lepiej choć nadal niedobrze, bo mamy dublujący się kod. Jest jeszcze mechanizm grup, ale nie do tego on służy (wbrew pozorom), bo i tak nie unikniemy tu sprawdzania typu.

Jeff Bay przychodzi z pomocą

W komentarzach do trzeciej części EOwP pojawiły się głosy, że dodatkowa warstwa nie jest potrzebna, bo tyko komplikuje kod. Tu jednak mamy dobre miejsce na wprowadzenie typu obudowującego.
Na początek definiujemy interfejs BussinesInt w klasie SomeClass:

Listing 5. Interfejs BussinesInt

public class SomeClass {

	protected static interface BussinesInt {
		Integer getValue();
	}

//...
}

Następnie dodajemy implementację w ramach klasy SomeClass:

Listing 5. Implementacja BussinesInt w SomeClass

public class SomeClass {

	private static class SomeBussinesInt implements BussinesInt {

		@NotNull
		private final Integer someInt;

		public SomeBussinesInt(Integer someInt) {
			this.someInt = someInt;
		}

		@Override
		public Integer getValue() {
			return someInt;
		}
	}

//...
}

oraz SubSomeClass:

Listing 6. Implementacja BussinesInt w SubSomeClass

public class SubSomeClass extends SomeClass {

	private static class SubSomeBussinesInt implements BussinesInt {

		@Null
		private final Integer someInt;

		public SubSomeBussinesInt(Integer someInt) {
			this.someInt = someInt;
		}

		@Override
		public Integer getValue() {
			return someInt;
		}
	}

//...
}

na koniec jeszcze kilka zmian w kodzie SomeClass:

Listing 7. Nowa wersja SomeClass

public class SomeClass {
//...
	@Valid
	private final BussinesInt someInt;

	public SomeClass(Integer someInt) {
		this.someInt = new SomeBussinesInt(someInt);
	}

	protected SomeClass(BussinesInt bussinesInt) {
		this.someInt = bussinesInt;
	}

	public Integer getSomeInt() {
		return someInt.getValue();
	}
}

i jedna bardzo istotna w SubSomeClass:

Listing 7. Nowa wersja SubSomeClass

public class SubSomeClass extends SomeClass {
//....
	public SubSomeClass(Integer someInt) {
		super(new SubSomeBussinesInt(someInt));
	}
}

Ok teraz pytanie co tu się stało?

Dlaczego tak?

Stajemy tu przed często spotykanym problemem dopuszczenia wyjątku jako normalnego zachowania.

W ogólności każdy obiekt SomeClass nie może mieć wartości null w swoim biznesowym polu. Jednak w przypadku SubSomeClass dopuszcza się tą wartość.

Obie klasy są prawidłowo umieszczone w hierarchii, obie zachowują się “na zewnątrz” w taki sam sposób. Inne są jednak zachowania wewnątrz klas. Tu mała uwaga, jeżeli podklasa zmienia zachowanie nadklasy w znaczący sposób np. umożliwia zwrócenie wartości null pomimo, że nadklasa wyraźnie tego zabrania to oznacza, że należy zmienić hierarchie klas. Tu nie ma takiego zagrożenia ponieważ metoda getSomeInt nie mówi nic o ograniczeniu wartości zwracanej więc null jest poprawnym wyjściem. Przykład z życia? Pracownik – handlowcy mają klientów asystenci handlowców nie mają klientów, ale są też handlowcami (nie dostają tylko bonusów z tytułu posiadania klientów).
klasy różnią się wewnętrzną obsługą jednego z pól zatem zamykamy to pole w specjalizowanym interfejsie, która może, ale nie musi być implementowany przez podklasy. Wystarczy zatem, że dodamy implementację tam gdzie tego potrzebujemy. Reszta bez zmian.

podsumowanie

JSR 303 fajne jest, ale ma wiele kruczków-sztuczków (Corvus Corvax Magicus), które czasami przyprawiają o ból głowy.

Dodaj do