Art. 118.
1. Kto w celu osiągnięcia korzyści majątkowej przedmiot będący nośnikiem utworu, artystycznego wykonania, fonogramu, wideogramu rozpowszechnianego lub zwielokrotnionego bez uprawnienia albo wbrew jego warunkom nabywa lub pomaga w jego zbyciu albo przedmiot ten przyjmuje lub pomaga w jego ukryciu, podlega karze pozbawienia wolności od 3 miesięcy do lat 5.
2. Jeżeli sprawca uczynił sobie z popełniania przestępstwa określonego w ust. 1 stałe źródło dochodu albo działalność przestępną, określoną w ust. 1, organizuje lub nią kieruje, podlega karze pozbawienia wolności od roku do lat 5.
3. Jeżeli na podstawie towarzyszących okoliczności sprawca przestępstwa określonego w ust. 1 lub 2 powinien i może przypuszczać, że przedmiot został uzyskany za pomocą czynu zabronionego, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.
Art. 118/1.
1. Kto wytwarza urządzenia lub ich komponenty przeznaczone do niedozwolonego usuwania lub obchodzenia skutecznych technicznych zabezpieczeń przed odtwarzaniem, przegrywaniem lub zwielokrotnianiem utworów lub przedmiotów praw pokrewnych albo dokonuje obrotu takimi urządzeniami lub ich komponentami, albo reklamuje je w celu sprzedaży lub najmu, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 3.
2. Kto posiada, przechowuje lub wykorzystuje urządzenia lub ich komponenty, o których mowa w ust. 1, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do roku.

Przy czym nas interesuje artykuł 118/1 (super metoda na nowelizację prawa bez wprowadzania zmian w numeracji – dodać indeks do numeru artykułu), który trafił do ustawy jako nowelizacja w 2000 AD.

Cóż on oznacza? Ano na zdrowy rozum oznacza on ni mniej ni więcej, że można każdego posadzić Dziś w standardzie komputera jest “urządzenie lub komponent” służący do powielania – nagrywarka. Oczywiście bez specjalistycznego oprogramowania nie można skopiować zabezpieczonej płyty, ale nie róbmy se jaj… takie programy są dostępne od ręki w necie jako różnego typu zgrywajki do ISO.

Ustawodawca jak zawsze podąża zgodnie kierunkiem wyznaczanym przez duch czasu i duch maszyny, ale jak widać zwrot jest nieteges…

Dodaj do

Listing 1. Definicja using w Scali

object Using{
    def using[A <: {def close(): Unit}, B](param: A)(f:A => B): B = {
       try{
          f(param)
       } finally {
          param.close();
       }
    }
}

I później użyć w kodzie:

Listing 2. Użycie using w Scali

using(statement.executeQuery("select * from dual")){ resultSet =>{
     // reszta kodu
  }
}

Taka konstrukcja przypomina żonę, która okazjonalnie zamknie deskę (o ile będzie w pobliżu czytaj mąż użyje using).
Generalnie w tym przypadku definiujemy funkcję, która jako parametr przyjmuje obiekt klasy, w której zdefiniowano metodę close() i dodatkowo przyjmuje jako drugi element coś, nazwane f co dokonuje transformacji A na B. To jest znany z Pythona tzw. “Duck Typing” (Jeżeli coś chodzi jak kaczka i kwacze jak kaczka to jest to kaczka – wnioskowanie typu na podstawie bebechów).

Jak widać konstrukcja jest fajna i przydatna. Zatem można by spróbować przenieść ją bezpośrednio do Javy (to też jest tresura małżeńska). Oczywiście jest to zabawka, której używanie w kodzie produkcyjnym jest średnio rozważne… ale niema ryzyka nie ma zabawy. Najwyżej się coś wywali.

Listing 3. Definicja using w Javie

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

/**
 * Emulator using ze Scali czy C#.
 *
 * @author bartlomiejk
 *
 */
public class Using {

	/**
	 * Wykonuje operacje z body poczym wywołuje close() z t.
	 *
	 * @param 
	 *            typ generyczny z metodą close()
	 * @param t
	 *            zasób.
	 * @param body
	 *            operacja do wykonania.
	 * @throws RuntimeException
	 *             w dwóch przypadkach:
	 *

	 *
Brak metody close().

	 *
Security Manager niepozwala na wywołanie metody close.

	 *             

	 */
	public static  void using(T t, Unit body) throws RuntimeException {
		Class tClass = t.getClass();
		try {
			Method method = tClass.getMethod("close");
			method.setAccessible(true);
			try {
				body.perform(t);
			} finally {
				method.invoke(t);
			}
		} catch (SecurityException e) {
			throw new RuntimeException(e);
		} catch (NoSuchMethodException e) {
			throw new RuntimeException(e);
		} catch (IllegalArgumentException e) {
			e.printStackTrace();
		} catch (IllegalAccessException e) {
			e.printStackTrace();
		} catch (InvocationTargetException e) {
			e.printStackTrace();
		}
	}

	/**
	 * Synchronizowana wersja {@link #using(Object, Unit)}. synchronizacja względem zasobu.
	 *
	 * @see Using#using(Object, Unit)
	 *
	 * @param 
	 *            typ generyczny z metodą close()
	 * @param t
	 *            zasób.
	 * @param body
	 *            operacja do wykonania.
	 * @throws RuntimeException
	 *             w dwóch przypadkach:
	 *

	 *
Brak metody close.

	 *
Security Manager niepozwala na wywołanie metody close.

	 *             

	 */
	public static  void s_using(T t, Unit body) {
		synchronized (t) {
			using(t, body);
		}
	}

	/**
	 * Interfejs jednostki kodu wywołanej w ramach try/finally.
	 *
	 * @author bartlomiejk
	 *
	 * @param 
	 *            typ generyczny wykorzystywanego zasobu.
	 */
	public interface Unit {
		/**
		 * Wywoływana jednostka kodu.
		 *
		 * @param t
		 *            zasób.
		 */
		public void perform(T t);
	}
}

Metoda using występuje też w synchronizowanej wersji s_using, a muteksem jest zasób. Do wykorzystania z zasobami wymagającymi synchronizacji np. plikami.

Listing 4. Użycie using w Javie

using(daoSupport.executeQuery(CACHE_SQL), new Unit() {
	@Override
	public void perform(ResultSet t) {
		try {
			while (t.next()) {
				//...
			}
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}
});

To tyle. Raz jeszcze kod jest ciekawostkowy, niedopracowany i pewno coś będzie wywalał. Zatem używacie na własne ryzyko. Licencja beerware.

Dodaj do

Zresztą był Napster, który nie trzymał się pierwszej zasady Jamesa Hetfielda, “jeżeni fanów nie stać na płyty Metallica’i to niech je ukradną”. Napster nie kradł. Później była Kazaa, czyli sieć wymiany wirusów i pornoli udających seriale. Kazaa przeszła na działalność komercyjną i chyba jeszcze żyje… o ile ktoś chce kupować zawirusowane pornole… choć z drugiej strony…

Później nastały czasy eDonkey i jego kolegi eMule, który działał tak jak się nazywał głupio i powoli. Teraz mamy torrenty, a jak ten sposób dystrybucji danych zostanie ograniczony to się wdroży coś innego. Jednym zdaniem ACTA-srakta siadamy wymyślamy nowy protokół wymiany danych (p2p + routing cebulowy + szyfrowanie). Zresztą samym korpo będzie zależało na jak najszybszym stworzeniu protokołów odpornych na ACTA. Nikt nie lubi jak mu władza grzebie w korespondencji.

ACTA to jednak nie tylko szeroko pojęte piractwo muzyczno programistyczne. ACTA to przede wszystkim umowa dotycząca patentów i własności przemysłowej. Po tygodniu sraczki związanej z zagrożeniem odcięciem od porno do dziennikarzy zaczyna powoli trafiać co oznacza ACTA dla przemysłu.

Ano będzie niewesoło. Producenci będą mogli bardzo szybko wykończyć rynek tzw. zamienników. Czy to części samochodowych czy to sprzętu komputerowego czy to w końcu najzwyklejszych wkładów do drukarek. Oczywiście nie nastąpi to od razu. Po prostu w miarę potrzeb będzie się przymykało oko albo producentów “podróbek”. Jeszcze gorszą wiadomością jest to, że ACTA dotyczy też rynku leków. Zatem żegnaj tania aspiryno z Polfy… trza będzie kupować znacznie droższą oryginalną aspirynę Bayera.

No i tyle w tej sprawie. W sumie może się za niedługo okazać, że bardziej niż wizyty policji z okazji pirackiej muzyki należy obawiać się wizyty na błogosławieństwo wymiany śrub w kole na pochodzące od innego dostawcy niż ten wskazany przez producenta.

// EDIT: Wśród sygnatariuszy są Japonia i Korea Południowa, czyli państwa w których dozwoloną praktyką jest szpiegostwo przemysłowe i generalnie podpierdalanie rozwiązań technicznych.

Dodaj do

Generalnie zarówno call jak i execution nie różnią się jeżeli chodzi o moment wywołania. Jeżeli zdefiniujemy, że mają być wkompilowane przed to zostaną wkompilowane przed. Jeżeli po to po. Kompilator zapewnia, że w danym przepływie sterowania aspekt będzie umieszczony w odpowiednim miejscu. Oczywiście przy założeniu, że nie ma tam jakiś dodatkowych aspektów. Różnica leży w tym gdzie kompilator umieszcza kod.

Położenie call

Jeżeli używamy call to kompilator umieści kod porady w miejscu gdzie wywoływana jest dana metoda. Czyli jeżeli metoda A.a woła metodę B.b to kod zostanie umieszczony w metodzie A.a.

Położenie execution

Jeżeli używamy execution to kompilator umieści kod w wywoływanej metodzie. Przykładowo jeżeli A.a woła B.b to kod zostanie umieszczony w B.b.

Gdzie jest to istotne

W praktyce jeżeli wrzucamy kod aspektowy do naszych klas to nie ma różnicy czy użyjemy call czy execution. Kompilator i tak musi przeorać cały kod źródłowy… no właśnie. Kod źródłowy… Jeżeli wasza metoda jest wywoływana przez jakaś zewnętrzną bibliotekę np. chcecie dodać kod aspektowy do testu oznaczonego @Test to użycie call skończy się komunikatem Xlint:adviceDidNotMatch. Kompilator nie doda waszej porady ponieważ nie pracuje na kodzie wywołującym metodę. Dotyczy to też sytuacji gdzie do wywołania metody używacie refleksji. W takim wypadku macie dwa wyjścia. Po pierwsze użyć execution, co jest prostsze, ale narusza wasz kod (przyjmuję tu pracę z weaveringiem w czasie kompilacji). Po drugie użyć call wraz z weaveringiem w czasie ładowania klas.

Dodaj do

Piątek, a zatem słuchamy Listy w Trójce. Przed nami ostatnia z zasad Jeff’a Bay’a

Nie używaj getterów/setterów/własności

Niewątpliwie jest to najbardziej obiektowa z zasad. By zrozumieć o co w niej chodzi porównajmy takie oto dwie klasy

Listing 1. klasa bardziej “obiektowa”

class Chłopiec{

	private String imię;

	private String nazwisko;

	private String wiek;

	public String getImię() {
		return imię;
	}

	public void setImię(String imię) {
		this.imię = imię;
	}

	public String getNazwisko() {
		return nazwisko;
	}

	public void setNazwisko(String nazwisko) {
		this.nazwisko = nazwisko;
	}

	public String getWiek() {
		return wiek;
	}

	public void setWiek(String wiek) {
		this.wiek = wiek;
	}

}

Listing 2. klasa mniej “obiektowa”

class Dziewczynka {

	public String imię;

	public String nazwisko;

	public String wiek;

}

Czym różnią się te dwie klasy?

Obiektowość to nie metody

Pomijając różne specyficzne elementy języka związane z współbieżną zmianą stanu obiektów tych klas to te dwa twory niczym się nie różnią. Mogę jednak założyć się, że jeżeli pokażemy je “nagie i bezbronne” to pierwsza z nich zostanie zakwalifikowana jako bardziej obiektowa. Druga będzie mniej obiektowa. Dlaczego? Jakoś tak się utarło, że o obiektowości decydują metody.
W Javie jest to szczególnie potęgowane przez specyfikację Java Beans:

Properties are always accessed via method calls on their owning object. For readable properties
there will be a getter method to read the property value. For writable properties there will be a
setter method to allow the property value to be updated.

Cóż… Ma to pewien cel i jest tu pewien pomysł, ale tylko gdy przyjrzymy się tej specyfikacji jako całości (szczególnie z obsługa zdarzeń i wzorcem obserwatora). Niestety jak to w życiu bywa, ktoś z całego dokumentu wyciągnął jeden fragment i tak oto znaleźliśmy się w życi.

Czym jest obiektowość?

Obiektowość to przede wszystkim enkapsulacja. Inaczej mówiąc obiekty nie powinny ujawniać swojego wnętrza, a jedynie udostępniać pewien interfejs, który będzie odwzorowywał operacje dokonywane przez obiekt. Oczywiście może się tak zdarzyć, że operacja polega na ustawieniu jakiejś wartości obiektu. Jednak są to specyficzne przypadki. W żadnym wypadku nie należy pozwalać na swobodną manipulację właściwościami obiektu.

Co zamiast?

Skoro nie powinniśmy mieć możliwości swobodnej manipulacji jak tworzyć i konfigurować obiekty? Z każdym z elementów zajmiemy się z osobna.

Settery

Generalnie obiekty powinny być niezmienne. Ma to wiele zalet. Najważniejszą jest możliwość swobodnego programowania współbieżnego bez obawy, że wątki wzajemnie pozmieniają sobie dane. W takim wypadku settery zostaną automatycznie wyrugowane przez mechanizmy języka wymuszające ustawienie pól w konstruktorze.
Jeżeli jednak z jakiegoś powodu nie możemy użyć pól finalnych to należy ustawić je z użyciem jakiegoś kontenera DI. Zazwyczaj mamy dostęp do tego typu bibliotek i nie ma problemów z ich wykorzystaniem.
Co jednak gdy z jakiś powodów kontener DI nie jest dostępny? W takim wypadku zostaje nam wykorzystanie wzorca fabryki wzbogaconego o użycie refleksji.

Właściwości

Unikamy sytuacji kiedy zachowanie obiektu zależy od właściwości. To właściwość powinna dostarczać odpowiedniego zachowania. Przykładowo w poprzedniej części mówiłem, że opakowane kolekcje powinny dostarczać metod “kontekstowych”. Podobnie w trzeciej części gdzie mowa była o opakowaniu typów prymitywnych wspominałem o możliwości zamknięcia w typie opakowującym pewnych prostych operacji np. walidacji czy operacji arytmetycznych.

Gettery

Najbardziej kłopotliwy element. Koniec końców zawsze musimy gdzieś pokazać uzyskaną wartość. Najprościej jest przesłonić toString. Nie zawsze się to da zrobić. O ile zadziała to w przypadku prostych obiektów to już obiekty złożone stanową duży problem. Pewnym rozwiązaniem może być użycie odpowiedniego prezentera, czyli wzorca MVP. Prezenter może dostać się do obiektu via refleksja względnie odpowiednio zinterpretować wyniki z metody toString. Wzorzec ten ma w tym przypadku wiele zalet. Jeżeli jednak chcemy zrobić coś małego to można użyć czegoś co roboczo nazywam obiektem “samopezentującym się”. W takim przypadku obiekt posiada metodę, do której można przekazać docelowe miejsce prezentacji np. strumień i tyle. Jest to rozwiązanie o tyle wygodne, że czasami chcemy ograniczyć możliwość prezentacji obiektu. W takim wypadku metoda pełni rolę swoistego “pasa cnoty” ponieważ ogranicza kanały prezentacji.

Podsumowanie

Uff… przebrnąłem. Nie było łatwo. Paweł Lipiński w komentarzu do siódmej części zwrócił uwagę, że są to przede wszystkim pewne heurystyki. W części zerowej wspomniałem, że zasady te są świetne jeżeli chcemy refaktoryzować kod. Są też doskonałym narzędziem do ćwiczenia. Zatem czy stosować zasady Jeff’a Bay’a? Moim zdaniem warto dążyć do kodu napisanego zgodnie z tymi zasadami. Ponieważ kod taki promuje przemyślane konstrukcje, pozwala na odnalezienie potencjalnie niebezpiecznych fragmentów i karkołomnych konstrukcji w architekturze oraz wymusza pisanie testów. Ja napisałem projekt zgodny z tymi zasadami mający około 1000 linii. Teraz czas byś usiadł i napisał swój projekt.

Dodaj do

Rzecz w tym, że mam kilka własnych walidatorów, które korzystają z danych pobranych z bazy. Dane sa pobierane raz i zapisywane w takim pseudo cache, który potrafi odpowiedzieć na różne pytania dotyczące poszczególnych banków (czy mają włączone pewne usługi, czy są aktywne itp.). Zatem chcąc przetestować to rozwiązanie należało by użyć mocka. Na tapetę trafia zatem Mockito i koleżanka Whendy, która będzie udawała nam bazę danych.

// offtopic:
koleżanka Whendy zawdzięcza swoje imię temu, że konfigurując mocka używamy metod when i then.
// koniec offtopicu

Szyba konfiguracja i dla mniejszych testów śmiga. Przy okazji chciałem sprawdzić jak to zagra w przypadku większego testu. Nadal bez bazy danych, ale już odpalając wszytko na raz. Wziąłem zatem dyżurny zestaw 100k transakcji testowych. Napisałem prosty test “profilujący” pod kątem czasu, odpaliłem i OutOfMemmoryError się stos skończył. Nosz… na razie bez przekleństw. Zaparzyłem świeżą kawę i dawaj sprawdzamy. Plik wejściowy ~41MB co daje jakieś ~70MB w obiektach. Do dyspozycji jest 256MB RAM dla JVM w TestNg. Hm… szybko dopinam Dupaprofiler dla pamięci i widzę, że wykłada się przy około ~40K obiektów. Na Twittera idą bluzgi w temacie JSR-303. Pól dnia walki i co się okazało?

Każdy mock ma dodatkowe featury

Generalnie każdy mock tworzony przy pomocy frameworku ma kilka fajnych fearturów. Jednym z nich jest zbieranie informacji o wywołaniach, argumentach przekazanych do obiektu itp. Te dane zżerają pamięć w zastraszającym tempie. Skończyło się na pseudoimpelentacji interfejsu. Działa tak samo jak mock, ale nie zbiera informacji o wywołaniach. Jeżeli zatem w trakcie testów kończy ci się pamięć to sprawdź czy twoje mocki nie są zbyt zasobożerne.
Jeżeli tak jest to sprawdź czy potrzebujesz informacji o wywołaniach. Jeżeli nie to wystarczy zamiast mocków z frameworku napisać własną pseudo implementację. Jeżeli potrzebujecie jednak pewnych informacji to nie pozostaje nic innego jak dołożyć pamięci.

Dodaj do

Mam rok 1971 DARPA^W otwiera sieć ARPANET^W publikując specyfikację TCP/IP. Dokonuje się kolejna rewolucja w przepływie informacji. Informacja może zostać przesłana z jednego końca świata na drugi w niewyobrażalnym tempie. W przeciągu kilkudziesięciu lat ilość informacji przesyłanych tą drogą rośnie do gigantycznych rozmiarów. Sieć okazuje się jednak niebezpieczna dla władzy. I to takiej rozumianej w normalny sposób – demokratycznej i kontrolowanej przez obywateli. Najzwyczajniej w świecie władza traci możliwość rządzenia – nikt nie jest wstanie ogarnąć takich ilości informacji. Jest jednak inna gorsza niż władza siła. Jest nią grupa gości, którzy odkrywają, że w epoce sieci komputerowych ich produkty i usługi nie są nikomu potrzebne. Tą grupą są wydawcy. Wykorzystują zatem swoje możliwości i zaczynają na wszelkie sposoby wpychać różne mechanizmy koncesjonowania sieci.

Za Janem Kochanowskim:

Nikomu, albo raczej wszytkim, swoje księgi
Daję. By kto nie mniemał (strach to bowiem tęgi),
Że za to trzeba co dać, wszyscy darmo miejcie.
O drukarzu nie mówię, z tym się zrozumiejcie

Ważna rzecz. Kochanowski jasno określił, że jego dzieła kosztują tyle ile uzgodnimy z drukarzem. Mówiąc językiem współczesnym Kochanowski wydał swoje dzieła na licencji CC-BY-ND. Jedyne co kosztuje to nośnik. W epoce internetu udało się wyeliminować “najdroższy” element – nośnik. Napisałem najdroższy w cudzysłowie ponieważ patrząc na rozkład kosztów płyty łatwo zauważymy, że lwia część trafia to dystrybutorów i wydawców. Sensem istnienia wydawców jest produkcja nośników. Eliminując nośnik eliminujemy wydawcę. Rozwój sieci spowodował realne zagrożenie dla fundamentalnego elementu decydującego o istnieniu wydawcy – nośnika. Nie jest to odkrywcze, ale dobrze tłumaczy dlaczego to wydawcy, a nie artyści są główną silą napędową cenzury.

Wniosek. W przeciągu kilkunastu kolejnych lat będziemy mieli jeszcze kilka prób wprowadzenia cenzury w sieci pod hasłem walki z piractwem. Broń nie jest jednak skierowana w piratów, ale ma na celu jak najdłuższą ochronę przestarzałej technologicznie płyty CD jako nośnika treści. Jeżeli udało by się wyeliminować z rynku fizyczny nośnik to w przeciągu kilkunastu lat znikną i wydawcy.

Dodaj do

Gladius Noctis, a na blogu ósma z zasad Jeff’a Bay’a

Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)

Nazwa trochę długa, ale nie ważne. Powróćmy na chwilę do pierwszej części tego cyklu. Na koniec przykładu z tablicami mieliśmy tam następujący kod:

Listing 1. Kod z pierwszej części

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		fillArray(array3d);

		printArray(array3d);

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillArray(int[][][] array3d) {
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static void print2dArray(int[][][] array3d, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			printRow(array3d, i, j);
			System.out.println();
		}
	}

	private static void printArray(int[][][] array3d) {
		for (int i = 0; i < array3d.length; i++) {
			print2dArray(array3d, i);
			System.out.println();
		}
	}

	private static void printRow(int[][][] array3d, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
	}

}

Przy tamtych założeniach było ok. Krawetko podał jeszcze zgrabniejszą wersję. Ja jednak zmienię tu wszystko.

Co robimy z kolekcjami?

Przede wszystkim iterujemy. Przeciskamy przez różne formy pętli w celu wykonania operacji na wszystkich elementach kolekcji. W Javie jest to dość upierdliwe. Za każdym razem należy napisać te klika linijek kodu by przepuścić daną kolekcję przez pętlę. W dodatku może okazać się, że coś skrewiliśmy albo nasz kod dostał się w niepowołane ręce, które wykonały kilka niefajnych operacji bezpośrednio na kolekcji.
W Scali jest trochę lepiej mamy metodę foreach, która opakowuje pętlę:

Listing 2. foreach w Scali

val x = 1 to 10
x foreach ($ => println($*$))

I już mamy kwadraty liczb od 1 do 10. W javie trzeba na to dwóch pętli.

Oczywiście jest tu ukryty mały "fakap" ponieważ zarówno metoda to jak i foreach maskują nam odpowiednie pętle. W przypadku to jest to jeszcze wzbogacone o lazy-init, ale to insza inszość.

Dlaczego opakowywać kolekcje?

Kod w Scali fajny jest. Dlatego warto stworzyć sobie podobne możliwości. W Javie nie jest to trudne generalnie poniższy kawałek kodu rzucił mi się kiedyś w oczy, ale skąd pochodzi ta koncepcja nie jestem wstanie powiedzieć.

Listing 3. foreach w Javie

interface Foreach {

	interface Action {
		void perform(T t);
	}

	abstract class ForeachImpl implements Foreach {

		private static class ArrayDelegate implements Foreach {

			private T[] array;

			public ArrayDelegate(T[] array) {
				this.array = array;
			}

			@Override
			public void foreach(Action action) {
				for (T t : array) {
					action.perform(t);
				}
			}
		}

		private static class Delegate extends ForeachImpl {

			public Delegate(Collection collection) {
				super(collection);
			}
		}

		public static  Foreach delegate(Collection collection) {
			return new Delegate(collection);
		}

		public static  Foreach delegate(D[] collection) {
			return new ArrayDelegate(collection);
		}

		private Collection collection;

		private ForeachImpl(Collection collection) {
			this.collection = collection;
		}

		@Override
		public void foreach(Action action) {
			for (T t : collection) {
				action.perform(t);
			}
		}
	}

	public void foreach(Action action);
}

Jest to trochę karkołomna konstrukcja w tej postaci, ale wiadomo o co chodzi. Odpowiednie zagłębienia służą tu odwaleniu roboty podobnej do tej jaką odwala scalac przy dodawaniu traita do klasy. Dla przypomnienia jeżeli trait nie zawiera implementacji to jest traktowany jak interfejs. Jeżeli zawiera implementacje to tworzone są klasy abstrakcyjne zawierające zaimplementowane metody i w klasie docelowej następuje delegacja zachowania do takiej wewnętrznej klasy. Tyle w skrócie zainteresowanych odsyłam do konsoli i polecenia javap.

Nasza klasy wystarczy, że zaimplementuje interfejs i wydeleguje obsługę metody do klasy Delegate. Już dużo mniej roboty później przy iterowaniu przez kolekcję wystarczy zaimplementować clou pętli czyli to co pomiędzy { i }. Można to też łatwo przetestować. Ba! Można implementację przerzucić na użytkownika API. Niech powie co robi z pojedynczym elementem kolekcji, a to jak będzie przechodził przez kolekcję to już nie jego sprawa. Tu dochodzimy do takiego modelu, który jest już blisko programowania funkcyjnego. Klient mówi CO i nie martwi się JAK.

Wypełniamy tablicę

Powróćmy do pierwszego kodu. W pierwszym kroku opakujmy tablicę jednowymiarową o zadanej ilości elementów w coś przyjaznego dla środowiska:

Listing 4. Opakowana tablica intów

class ArrayOfInt {

	private Integer array[];

	public ArrayOfInt(int size) {
		array = new Integer[size];
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		int next = start;
		for (int i = 0; i < array.length; i++) {
			array[i] = next;
			next += step;
		}
		return next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Integer t) {
				System.out.print(String.format("%2s ", t));

			}
		});
	}

}

Ok, na razie nic groźnego. O ile inicjację tablicy i jej wypełnienie musimy przeprowadzić iterując z palucha to już wypisanie robimy za pomocą delegowania.
Teraz czas na tablicę dwu wymiarową. W tym przypadku musimy powiedzieć ile kolumn i ile rzędów chcemy mieć. Jednak czy aby na pewno? Opakowujemy w końcu kolekcję kolekcji... zatem...

Listing 5. Opakowana dwu wymiarowa tablica intów

class Array2dInt {

	private class Next {
		int next;
	}

	private ArrayOfInt array[];

	public Array2dInt(int rows, int cols) {
		array = new ArrayOfInt[rows];
		for (int i = 0; i < array.length; i++)
			array[i] = new ArrayOfInt(cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Whoa... inicjacja w konstruktorze nadal z palucha (tego nie przeskoczymy). Reszta przez delegaty. Tablica trójwymiarowa to już formalność.

Listing 5. Opakowana trójwymiarowa tablica intów

class Array3dInt {

	private class Next {
		int next;
	}

	private Array2dInt array[];

	public Array3dInt(int rows, int cols, int depth) {
		array = new Array2dInt[depth];
		for (int i = 0; i < array.length; i++)
			array[i] = new Array2dInt(rows, cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Całość można oczywiście ładnie rozdzielić na nieanonimowe klasy wewnętrzne (albo wyrzucić do osobnych klas o ograniczonej widoczności) czy uczynić generycznym. Cały kod jest, wbrew pozorom, prostszy i łatwiejszy w testowaniu.

Podsumowanie

Bardzo istotną rzeczą w takim podejściu do kodowania jest umiejętność rozdzielenia swojej osobowości na klienta i dostawcę. W przeciwnym wypadku możemy nieźle przestraszyć się ilością kodu.

Najistotniejszą cechą jest jednak ograniczenie klientowi pola manewru w pracy z kolekcją. Mając ograniczone API i pozbawiając go możliwości dowolnego manipulowania elementami możemy się zabezpieczyć przed nieprzyjemnymi sytuacjami jak chociażby usunięcie elementu z kolekcji (boli jak używasz JPA), głębokie klonowanie kolekcji albo nieskończonego iterowania.
Dodatkowo operacje biznesowe są jasno określone przez co zmniejsza się prawdopodobieństwo "hakierowania" i tworzenia obejść we właściwym kodzie biznesowym.

Gdzie warto używać

Przede wszystkim warto opakowywać kolekcje, które wychodzą z bazy danych/DAO. W ten sposób można ograniczyć manipulowanie obiektami w ramach kodu biznesowego. Wszelkie operacje związane ze zmianą stanu bazy będą dokonywane poprzez interfejs opakowanej kolekcji. Dzięki czemu można kontrolować kto co może. W takim układzie aplikacja nie widzi DAO jako takiego. Widzi tylko interfejs dostarczający pewne dane na których można wykonać ściśle określone operacje.
Po drugie MVP. W tym przypadku kolekcja staje się pomocnikiem dla prezentera. Można dzięki temu wprowadzić np. dodatkowe filtrowanie danych tuż przed ich wyświetleniem. To pozwala na stworzenie jednego prezentera, który będzie prezentował dane w zależności od potrzeb, ale będzie jednocześnie na tyle elastyczny by móc z niego skorzystać w wielu miejscach. Przykładowo kolekcja A przed wyświetleniem wymaga wycięcia części danych, których nie bardzo można pozbyć się na etapie pobierania z bazy. Jednocześnie kolekcja B nie ma tych danych już domyślnie. Obie mają metodę show przyjmującą jako parametr prezenter. Następnie w środku wywołują tylko wybrane metody prezentera.
Po trzecie filtry. W takim przypadku zamiast pozwolić iterować po kolekcji możemy udostępnić klientowi ileś tam predefiniowanych metod, które filtrują kolekcję w określony sposób. Tu mała uwaga. Szkoda, że w Javie nie ma eleganckich domknięć i trzeba stosować haki w stylu anonimowych klas.

Dodaj do

By ogarnąć DI należy napisać jeden projekt bez użycia słowa kluczowego new w kodzie biznesowym. Można go używać w provideach. Dozwolone jest też tworzenie prymitywów i Stringów “z palca”.

Dodaj do

Generalnie po ustawieniu pola chcemy wykonać pewne operacje.

Wstrzykiwanie via setter

W guice adnotujemy @Inject metodę (dowolna nazwa, widoczność itp.) i to wszystko. Problem polega na tym, że obiekt jest w stanie nieokreślonym. Raz, że jego tworzenie jeszcze trwa, a dwa, że nie mamy kontroli nad kolejnością wywoływania metod.

Wstrzykiwanie via pole + @PostConstruct

W tym przypadku w momencie gdy metoda/y oznaczone @PostConstruct są wywoływane mamy pewność, że obiekt jest już zainicjowany i spójny. Plusem jest tu też możliwość ukrycia implementacji (brak setterów, metoda może być niewidoczna). Nadal nie mamy kontroli nad kolejnością wywołań w przypadku wielu metod @PostConstruct, ale zazwyczaj jedna wystarczy by w niej wykonać określone akcje w zadanej kolejności.

Gdzie to jest ważne

Takie coś może okazać się bardzo istotne w momencie gdy robicie DI na elementach GUI. Większość silników UI ma to do siebie, że dodając komponenty robi to w kolejności wywołania metod. Jedynym wyjątkiem są siatki, gdzie można kontrolować położenie komponentu w przestrzeni. Trochę inaczej ma się to w przypadku managerów wyglądu typu Vertical/Horizontal. Tam istotna jest kolejność wywołania metody. Zatem jeżeli nie chcecie stopki na górze strony…

Dodaj do