• Zmiana stanu obiektu gdy jest on przekazany do metody, zwłaszcza funkcji, której nazwa sugeruje że jest to bezpieczne
• Zmiana stanu w wyniku współbieżnego dostępu do jednego obiektu

Z pierwszym przypadkiem można sobie poradzić przez bardzo restrykcyjne pilnowanie innych członków zespołu na przeglądach kodu, to rozwiązanie zawodzi gdy korzystamy z zewnętrznych bibliotek.

Drugi problem nie występuje do puki nie współdzielimy obiektów między wątkami. Z taką sytuacją mamy do czynienia na początku rozwoju każdej aplikacji. Wystarczy jednak wprowadzić dodatkowy wątek (np. przez użycie niektórych metod asynchronicznych), albo dodać statyczne pole do kontrolera aby się na niego narazić.

Rozwiązaniem obu problemów są obiekty niezmienne, czyli takie, czyli takie których pola nie ulegają zmianie po utworzeniu. W C# i Javie aby stworzyć klasę, której instancje będą niezmienne należy zadeklarować wszystkie pola jako prywatne, ustawić je w konstruktorze i nie udostępnić żadnej metody je modyfikujące.

public class Address 
{
	private readonly string addressLine1;
	private readonly string addressLine2;
	private readonly string zipCode;
	private readonly string city;
	private readonly string stateArea;
	private readonly string country;

	public Address(string addressLine1, string addressLine2, string zipCode, string city, string stateArea, string country)
	{
		 this.addressLine1 = addressLine1;
		 this.addressLine2 = addressLine2;
		 this.zipCode = zipCode;
		 this.city = city;
		 this.stateArea = stateArea;
		 this.country = country;
	}

	public string AddressLine1 { get { return addressLine1; } }
	public string AddressLine2 { get { return addressLine2; } }
	public string ZipCode { get { return zipCode; } }
	public string City { get { return city; } }
	public string StateArea { get { return stateArea; } }
	public string Country { get { return country; } }
}

Problemy językowe

Obiekty niezmienne są jednak słabo wspierane przez C# i Javę.

Pierwszym problemem są pola opcjonalne, domyślnie konstruktor musi ustawić wszystkie, więc albo użytkownik takiego obiektu musi przekazać wartości domyślne do takiego obiektu.

Jeżeli obiekt ma wiele pól to konstruktor staje się długi, a pomyłki związane z przekazaniem wartości do złego pola trudno zauważalne. Poniższy kod zawiera błąd, jednak wcale nie wygląda podejrzanie:

var address = new Address (
	"Konwaliowa 31/20",
	"20036",
	"Lublin",
	"",
	"",
	"");

Jakimś rozwiązaniem jest zastosowanie przeciążeń konstruktora i wartości domyślnych dla jego parametrów, to rozwiązanie sprawdza się gdy klasa ma do 3-4 opcjonalnych pól, przy większej ilości szybko prowadzi do eksplozji kombinatorycznej ilości konstruktorów.

Problem staje się jeszcze bardziej dotkliwy gdy pojawia się potrzeba „zmodyfikowania” takiego obiektu, ponieważ obiektu nie da się zmienić, należy utworzyć nowy obiekt i przekazać do niego zarówno wartości zmienionych pól jak i tych, które zostają bez zmian.

var templateAddress = new Address(
	"Konwaliowa 31/20",
	"",
	"20036",
	"Lublin",
	"Lubelskie",
	"Polska");

var modifedAddress = new Address(
	"Konwaliowa 31/21",
	templateAddress.AddressLine2,
	templateAddress.ZipCode,
	templateAddress.City,
	templateAddress.StateArea,
	templateAddress.Country);

Monika Konieczny – Gramification

Ciekawy temat, niezbyt ciekawe wykonanie. Wykład dotyczył kolejnej metody motywacji pracowników, w tym programistów. Metoda ta polega na wprowadzeniu elementów gry podczas realizacji projektu, tak aby pracownicy czerpali radość z pracy. Jako przykład podany zostało rozgrywanie jakiejś gry w określonych odstępach czasu przy czym warunki początkowe gracza zależą od jego tygodniowych wyników (np. liczba kulek do Paintboala rozdawanych w comiesięcznej rozgrywce zależy od części projektu jaki wykonał pracownik). Według prelentki powinno się jednak szybko z gier indywidualnych przechodzić do zespołowych. Ogólnie prezentację oceniam na dobry minus.

Greg Young – zapomnij o szczegółach liczy się efekt

O autorze tej prezentacji przeczytałem na blogu Sławka Sobótki. Początkowo sądziłem że Sławek przesadza z mówiąc że wysłuchanie Grega powoduje efekt "I know kung-fu". Jednak później się przekonałem, że ma rację. Prelekcja była skierowana głównie do programistów Java, dlatego skrytykował on na samym początku używanie potężnych Framewoków i bibliotek w projektach w których samo ich skonfigurowanie zajmuje więcej czasu niż wykonanie projektu, dodatkowo powodując całą masę dziwnych błędów. Jak to określił "Frameworks are DSLs to converting XML into exceptions". Przez dłuższy czas było precyzowane stwierdzenie że klasa rozwiązań powinna być dobrana do klasy problemu. Że zupełnie inne rozwiązania powinno się stosować pisząc pamiętnik dla młodszej siostry, a inne tworząc aplikację nadzorującą działanie układu chłodzącego rdzeń elektrowni atomowej. Greg poruszył też zagadnienie zaciągania "technologicznego długu" podczas pracy nad projektem. Zastosował on sformuowania "Dobry dług" i "Zły dług" zaczerpnięte z publikacji Roberta Kiyosaki. Jedna z wypowiedzi mówiła o zasadności (nie)stosowania testów jednostkowych w projektach które będą rozwijane nie dłużej niż 2-5 lat. Według programistów pisanie testów jest dobrym zachowaniem, jednak wg. kadry zarządzającej powoduje całą masę pracy, która kosztuje i zmniejsza dochodowość projektu. Greg bardzo trafniej porównał stosowanie Testów jednostkowych do wzięcia na kredyt Lamborgini. Dla osób dla których kluczowym elementem sukcesu jest wizerunek (np. gwiazdy sportu i filmowe, prezesi dużych przedsiębiorstw) jest to z pewnością inwestycja("Dobry dług"), jednak dla przeciętnego zjadacza chleba koszty kredytu i utrzymania samochodu tej klasy przewyższają zarówno potencjalny wzrost zarobków a nawet same zarobki("zły dług") i analogicznie stosowanie testów jednostkowych ma sens w systemie bankowym gdzie pomyłka w algorytmie naliczania odsetek może kosztować zarówno bank jak i producenta oprogramowania miliony złotych, jednak mija się z celem w aplikacji napisanej dla sklepu ze skarpetkami gdzie na upartego można w ciągu jednej nocy wprowadzić ponownie wszystkie wystawione i odebrane faktury z ostatniego miesiąca. Kolejną kwestią poruszoną przez Grega była kwestia wzorców projektowych i sensu ich stosowania. Skrytykował on podejście w którym na siłę próbuje się stosować wzorce projektowe (tylko po to by je stosować). Podkreślił jednak ich rolę w komunikacji między proramistami (podając jako przykład Fabrykę Fabryk Fabryk której opisanie bez znajomości wzorców zajęłoby więcej niż ten wpis na blogu).

Ciekawostką jest fakt iż Greg nie posiadał przygotowanej prezentacji także nawet nie włączył projektora.

Michał Gruchała – Architektura skalowalnych systemów Webowych

Prezentacja dotyczyła zagadnienia optymalizacji prostych serwisów poddawanych bardzo dużemu obciążeniu (rzędu kilku milionów wejść na godzinę). Z racji że nie zajmuje się tym zagadnieniem nie specjalnie słuchałem prelegenta.

Sławomir Sobótka – Nowe bardziej racjonalne podejście do warstw

Prezentacja Sławka dotyczyła CQRS (Command Query Responsibility Segregation) która jest rozwinięciem Domain Driven Design. Podejście to zaleca oddzielenie serwisu zwracającego dane od serwisu je zmieniającego, co w dużym uproszczeniu oznacza rezygnację ze zwracania jakiś wartości przez metody które dokonują jakichkolwiek zmian w składowanych danych, oraz rezygnację z modyfikowania danych w metodach dane zwracające. Sławek podobnie jak Greg zwracał uwagę na zastosowanie na dostosowanie rozwiązania do problemu oraz że Domain Driver Design ma zastosowanie głównie przy pisaniu złożonych aplikacji biznesowych, z resztą wyraźnie widać było że Sławek przesiąkł myślą techniczną Greg'a. Nie czuję się na siłach aby przekazać ideę całego wykładu ponieważ sam muszę ją zgłębić.

Stephan Hochdöerfer – DDD jeszcze raz ale inaczej

Podobnie jak pierwsza prelekcja Ciekawy temat nieciekawe wykonanie.

Greg Young – Uwolnij swoją domenę

Wykład ten można potraktować jako rozwinięcie wcześniejszego wykładu Grega i wykładu Sławka Sobótki. Podobnie jak w przykładzie prezentacji Sławka nie podejmuje się analizy tego wystąpienia.

Ogólnie konferencję oceniam bardzo dobrze, a napewno lepiej niż zeszłoroczną. Lepiej dobrano lokalizację (Hotel w Poznaniu śmierdział według mnie komuną, a budynek Wyższej Szkoły Menagerskiej w Warszawie nawet jeżeli nie był nowy to był bardzo dobrze odnowiony), do zalet należy też zaliczyć fakt iż w tym roku posiłek był wliczony w koszt konferencji, oraz że nie zabrakło przystawek. Do wad lokalizacji należy zaliczyć dużą odległość od centrum Warszawy oraz brak ścieżki .Net oraz przedstawicieli firm Adobe, Microsoft i Oracle (może i byli ale ich widać nie było).

class Moja {

	/**
	 * 
	 * Pseudorzutowanie na typ
	 * @param mixed $item
	 * @return Moja
	 */
	public static function Cast($item) {
		return $item;
	}

	public function JakasFunkcja() {
		;
	}	
}

Teraz mogę sobie w kodzie spokojnie zwracać wyniku typu tablicowego i iterować po nim:

W tej chwili jedyną wadą tego rozwiązania jaka mi przychodzi do głowy jest dodatkowa ilość generowanego kodu.