Archive

Posts Tagged ‘dziwne konstrukcje’

Wyświetlanie nazwy wykonywanej metody

29/01/2013 Dodaj komentarz

Ostatni miałem potrzebę tworzenia wielu (testowych) podobnych metod. Technika kopiuj, wklej i zmiana dla potrzeb danego przypadku. Pierwsza wpis w każdej metodzie to wyświetlenie krótkiej informacji o tym co jest wywoływane. Dawało to informacje o tym co się dzieje w historii wywołań. Metody przybierały postać jak poniżej:

	public void doSomthing1() {
		System.out.println("doSomthing1");
		// ...
	}
	public void doSomthing2() {
		System.out.println("doSomthing2");
		// ...
	}

Tak więc zawsze występowała potrzeba poprawy nazwy w pierwszej linii. Było to trochę uciążliwe, więc wynikła potrzeba wprowadzenia udogodnienia, co poskutkowało takim kodem:

	public void doSomthing3() {
		System.out.println(MethodHelper.getExecutedMethodName());
		// ...
	}

Implementacja tej metody poniżej. Nie jest ona może najpiękniejsza, ale spełnia swoje zadania. Po fakcie w internecie znalazłem wpisy o tym, że nie tylko ja miałem potrzebę posiadania takiej metody.

	public static String getExecutedMethodName() {
		StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
		boolean next = false;
		for (StackTraceElement stackTraceElement : stackTrace) {
			String string = stackTraceElement.getMethodName();
			if (next) {
				return string+" line:"+stackTraceElement.getLineNumber();
			}
			if ("getExecutedMethodName".equals(string)) {
				next = true;
				continue;
			}
		}
		return "Metchod Name Not Found";
	}

Jeszcze na koniec dokonałem pewnego usprawnienia. Dodałem wpis o linii w której jest wykonywane wywołanie ;).
Tak wiec rozpoznanie co się dzieje w kodzie w postaci brutalnego stylu jak poniżej, także jest łatwiejsze

	public void doSomthing3() {
		System.out.println("doSomthing3: 1");
		// some code
		System.out.println("doSomthing3: 2");
		// some code
		System.out.println("doSomthing3: 3");
		// some code
	}

i może wyglądać tak:

	public void doSomthing3() {
		System.out.println(MethodHelper.getExecutedMethodName());
		// some code
		System.out.println(MethodHelper.getExecutedMethodName());
		// some code
		System.out.println(MethodHelper.getExecutedMethodName());
		// some code
	}
Kategorie:Java Tags: ,

Opakowanie wynik zapytani JPA do DTO – jeszcze raz

14/09/2011 Dodaj komentarz

W ostatnim wpisie, prawiłem jak to dobrze jest w niektórych przypadkach napisać trochę więcej kod, aby nie gmatwać się później. Tą większą ilością kodu było tworzenie nowej klasy typu DTO, do użycia w zapytaniach JPA. Gmatwaniną był bałagan powstający ze zbyt uporczywej re-używalności encji jako DTO.
Niedługo po tym zdarzył mi się przypadek, który wymagał zastosowania się do tej zasady (przy okazji wyszło że łatwo jest gadać jakie to „ma być”, a jak już ma się to zastosować, to wychodzi że nie jest to takie oczywiste i bezbolesne ;)).
Przechodząc do setna: realizacja tego dla przykładowych encji:

@Entity
@Table(name = "PARENT")
public class Parent {

	@Id
	@GeneratedValue
	@Column(name = "ID")
	private Long id;
	
	@Column(name = "NAME")
	private String name;
	
    @OneToOne(fetch=FetchType.LAZY, cascade={CascadeType.ALL})
    @JoinColumn(name="CHILDREN_ID")
	private Children children;
	
	// getters, setters
}
...
@Entity
@Table(name = "CHILDREN")
public class Children {

	@Id
	@GeneratedValue
	@Column(name = "ID")
	private Long id;
	
	@Column(name = "NAME")
	private String name;

	// getters, setters
}

sprowadza się to do takiego kodu:

		List<Object[]> tempList = entityManager
		.createQuery("select d.name, d.children.name from Parent d")
		.getResultList();
		List<Parent> returnList = null;
		if (tempList == null) {
			// to jest trochę defensywne zachowanie, 
			// niby specyfikacja nie wspomina o tym że może być null
			returnList = Collections.emptyList();
		} else {
			returnList = new ArrayList<Parent>();
			for (Object[] record : tempList) {
				Parent parent = new Parent();
				parent.setName((String)record[0]);
				parent.setChildren(new Children());
				parent.getChildren().setName((String)record[1]);
				returnList.add(parent);
			}
		}

Tutaj dla uproszczenia nie wprowadzałem już osobnego DTO. Widać tu jednak jak można konstruować zapytania tak aby pobierać to co się chce i żeby było to umieszczane w odpowiednich miejscach.
Jest oczywiście prostsza metoda, z delegacją cześć zadania do konstruktora, przykład:

		List<Parent> returnList = entityManager
		.createQuery("select new Parent(d.name, d.children.name) from Parent d")
		.getResultList();

Jednak w tym przypadku rozdzielamy informacje o tym „co” „gdzie” ma być umieszczone. To też było kłopotem dla mnie, opisywałem to dawniej; przedstawiałem tam także zarys sposobu jak chciałem to usprawnić. Jednak z czasem zebrana wiedza uleżała się i dzięki sposobowi który opisywałem jeszcze w innym poście wiem jak to zrobić. Co też opisze dalej.
Czytaj dalej…

Kategorie:Java Tags: , ,

Konstrukcja try inaczej

21/08/2011 Dodaj komentarz

Sposób na przedstawienie inaczej tego co jest wyrażana za pomocą konstrukcji try. Normalnie try w całej okazałości prezentuje się tak:

try {
   // wykonywane w try
} catch (NullPointerException e) { 
   // wykonywane w catch, w tym przypadku dla NullPointerException 
} finally { 
   // wykonywane w finally 
}

A ostatnio wpadłem na sposób jak można to zrobić zastępując całość specjalnym obiektem. W kodzie wygląda to jak poniżej:

// deklaracja
OtherTry otherTry = new OtherTry();
otherTry.addCatchBlock(new CatchBlock<NullPointerException>() {
    public void doWith(NullPointerException e) {
        // wykonywane w catch, w tym przypadku dla NullPointerException 
    }
});
otherTry.addFinallyBlock(new FinallyBlock() {
    public void doIt() {
        // wykonywane w finally 
    }
});
// użycie
otherTry.start();
    // wykonywane w try
otherTry.close();

Jest to trochę „sztuka dla sztuki” 🙂 choćby z powodu tego że zapis jest bardziej rozwlekły. Choć obiekt można zdefiniować tylko raz i potem używać w wielu miejscach (wtedy to tylko 2 linijki).
Całość ma jednak jedną wadę: nie zadziała z checked exception (kompilator nie pozwoli, i trzeba użyć starego try_a).

Ciekawej jest to, że można takie dziwo wyprodukować. W przypadku wyjątku pożądany kod obsługi się wykona, i jeszcze można zdefiniować sekcje finally. Możliwe jest to poprze dobranie się do bieżącego wątku i czasowe zmodyfikowanie domyślnego sposobu w jaki obsługiwane są nieprzechwycone wyjątki.
Czytaj dalej…

Kategorie:Java Tags: ,

Mała, ciekawa i inspirująca biblioteka do budowania Builderów

19/04/2011 Dodaj komentarz

Dziś wpadłem na informacje o bibliotece make-it-easy, ten link pokazuje do czego to służy. Streszczając jest to coś co ma uprościć pisane kodu pełniącego role podobną jak to jest w przypadku wzorca builder. No i tyle :).
Urzekła mnie w tym prostota wyrażenia tego co chcemy budować oraz opis jak to chcemy robić. Sam też niedawno próbowałem wdrożyć swój pomysł na to, ale utknąłem przez to że chciałem zrobić to zbyt prosto, zatrudniając przy tym zbyt ciężkie rozwiązania (refleksja i generowanie proxy).
Tak więc dzięki tej bibliotece można robić rzeczy które pokrótce opiszę. Na koniec dostarczę prostą implementacje, która używa trochę inne notacji.
Czytaj dalej…

Kategorie:Java Tags: ,

Tail recursive

25/01/2011 Dodaj komentarz

Zaczyna się jak kolejny wpis w stylu „java też tak może” (przykład innego tutaj).
Ostatnio doszła mnie wieść o cesze języka Scala, która to kryje się za pojęciem ‚tail recursive’. Poszukiwanie tego co to znaczy doprowadziło mnie między innymi do tego wpisu. Jest tu w miarę łopatologiczne wytłumaczenie o co chodzi w tym. Upraszczając: za tym pojęciem kryje się rodzaj pisania rekurencji w ten sposób, aby nie doprowadzić do jej wyłożenia się kiedy będzie biegła ona ku (prawie) nieskończoności.
Rekurencja nie jest mym chlebem powszednim w javie (i nie tylko) ;). Ciekawe czy jest to rodzaj wpojonego przekonania, czy z biegiem lat nabyte podskórne przekonanie, że nie tędy droga? Generalnie wiem, że w javie jest to możliwe, ale stosowanie tego w nadmiarze (nie rozważnie) może prowadzić do braku pamięci.
Wpis, do którego się tu odnoszę, podpuścił mnie do sprawdzenia czy może jedna java da radę.
Czytaj dalej…

Kategorie:Java Tags: ,

Dalej dziwne konstrukcje

27/12/2010 Dodaj komentarz

Wpadłem ostatnio w nastrój tworzenia niewielkich konstrukcji, które mogą zamknąć, w „zgrabniejszy” sposób, koncepcje jakie stoją za danym fragmentem kodu. Zaczęło się to chyba z tym postem.
Pisanie w ten sposób jest próbą wyrażenia inaczej czegoś co i tak najczęściej ląduje w statycznych metodach narzędziowych.
Głównym kryterium jest tu jak najlepsze wyrażenie koncepcji, kosztem wydajności, czy czasem nieporadności konstrukcji – stąd te dziwne konstrukcje ;).

Pierwszym przykładem jest swich na stringach. Nie będę tu oceniał zasadności takiej struktury. Podobno ma wejść to z nową wersją javy, ale jak to pokaże niże, można to mieć już teraz.

Ważne jest uświadomienie sobie czego się chcę. Czy słówko kluczowe akceptujące konkretny rodzaj argumentów? Czy realizacje określonego sposobu kodowania w oparciu o dany rodzaj argumentu?
Czytaj dalej…

Kategorie:Java Tags: ,

Dziwna konstrukcja

17/11/2010 Dodaj komentarz

Takie małe rozważanie na temat pewnej konstrukcji, sprawdza ona czy jest odpowiednia zmienna ustawiona.
W orginale były enum_y, ale tu są stringi dla prostoty.
Kod ma się tak:

		String currentType = "typ_3";
		if ("typ_1".equals(currentType) || "typ_2".equals(currentType) ||
				"typ_3".equals(currentType)) {
			System.out.println("currentType jest odpowiedni");
		}

Potrzeba jest jasnego zakomunikowania że do warunku można wejść kiedy currentType ma jedną z zadanych wartości. Niby jest to czytelne, ale czy można wyrazić to lepiej? 😉 zawsze można gdybać jakby to wyglądało gdyby dozwolonych wartości było więcej.

Powstały konstrukcje jak poniżej – w wyniku początkowego skojarzenia z pythonem i takiego przykładu z niego:

current_type = "typ_3"
if (current_type in ["typ_1", "typ_2", "typ_3"]):
    print "current_type jest odpowiedni"

Czytaj dalej…

Kategorie:Java Tags: ,