Forum PHP.pl

Odpal sobie to i testuj. Może ułatwi Ci to pracę z kodem. Ilość IF'ów minimalnie zmniejszyłem ;-). Sprawa jest o tyle ciężka, że tutaj mamy przekazane parametry, które mogą, ale nie muszą być zmieniane w trakcie wykonania funkcji dlatego do funkcji getI, getU itd. trzeba przekazać wszystkie parametry. Jest na to sposób - zastosować klasę i zmienne klasy. Powodzenia.

[PHP] pobierz, plaintext 
testLeitwerg();
 
function testSingle( $u, $r, $i, $g ) {
	$old = old_leitwert( $u, $r, $i, $g);
	$new = leitwert( $u, $r, $i, $g);
	$res = array_diff($old, $new);
	if( !empty( $res ) ){
		echo "ERR;";
 
	} else {
		echo "OK;";
	}
	echo "  params: $u, $r, $i, $g <br />"; 
	var_dump( $old );
	var_dump( $new );
 
}
 
function testLeitwerg(){
	/* testSingle( 0, 2, 2, 2 );
	testSingle( 2, 0, 2, 2 );
	testSingle( 2, 2, 0, 2 );
	testSingle( 2, 2, 2, 0 ); */
 
	testSingle( 15, 6, 2, 2 );
 	testSingle( 666, 8, 2, 2 );
	testSingle( 54, 2, 3, 6 );
	testSingle( 54544, 1, 2, 23 ); 
}
 
function old_leitwert($u, $r, $i, $g) {
	# 1
	if ( $u AND $i ) {
		$r = $u/$i;
		$g = 1/$r;
	}
 
	 # 2
	 if ( $i AND $r ) {
		$u = $r*$i;
		$g = 1/$r;
	}
 
	 # 3
	if ( $u AND $r ) {
		$i = $u/$r;
		$g = 1/$r;
	}
 
	# 4
	if ( $g AND $i ) {
		$r = 1/$g;
		$u = $r*$i;
	}
 
	#5
	if ( $u AND $r ) {
		$g = 1/$r;
		$i = $u/$r;
	}
 
	# 6
	if ( $u AND $g ) {
		$i = $u*$g;
		$r = $u/$i;
	}
 
	# 7
	if ( $i AND $r ) {
		$u = $i*$r;
		$g = 1/$r;
	}
 
	# 8
	if ( $g ) {
		$r = 1/$g;
	}
 
	# 9
	if ( $r ) {
		$g = 1/$r;
	}  
 
	return array('r' => $r, 'u' => $u, 'i' => $i, 'g' => $g );
}
 
function leitwert($u, $r, $i, $g) {
	echo 'NEW: <br />';	
	# 1
	$r = getR( $u, $r, $i, $g );
	$g = getG( $u, $r, $i, $g );
 
        # 2
	$u = getU( $u, $r, $i, $g );
	$g = getG( $u, $r, $i, $g );
 
	# 3
	$i = getI( $u, $r, $i, $g) ;
	$g = getG( $u, $r, $i, $g );
 
	# 4
	$r = getR( $u, $r, $i, $g );
	$u = getU( $u, $r, $i, $g );
 
	# 5
	$g = getG( $u, $r, $i, $g );
	$i = getI( $u, $r, $i, $g );
 
	# 6
	$i = getI( $u, $r, $i, $g );
	$r = getR( $u, $r, $i, $g );
 
	# 7
	$u = getU( $u, $r, $i, $g );
	$g = getG( $u, $r, $i, $g );
 
	# 8
	$r = getR( $u, $r, $i, $g );
 
	# 9
	$g = getG( $u, $r, $i, $g ); 
 
	return array('r' => $r, 'u' => $u, 'i' => $i, 'g' => $g );
}
 
function getR( &$u, &$r, &$i, &$g ){
	if ( $g OR ($g AND $i) ) {
		$r = 1/$g;
	}
	if ( ($u AND $g) OR ($u AND $i) ) {
		$r = $u/$i;
	} 
	return $r;
}
function getG( &$u, &$r, &$i, &$g ){
	if ( $r OR ($r AND $u) OR ($r AND $i) OR ($g AND $i) OR ($u AND $i) ) {
		$g = 1/$r;
	} 
	return $g;
}
function getU( &$u, &$r, &$i, &$g ){
	if ( $i AND ($g OR $r) ) {
		$u = $i*$r;
	}
	return $u;
}
function getI(  &$u, &$r, &$i, &$g ){
	if ( $u AND $g ) {
		$i = $u*$g;
	}
	if ( $u AND $r ) {
		$i = $u/$r;
	}
	return $i;
}
[PHP] pobierz, plaintext 

Dokładnie tak się powinno trworzyć aplikację. Uelastycznianie na wyrost to poważny błąd. A co jeśli w aplikacji będzie 4 aktorów o różnych imieniach i przez kolejne 10 lat nic poza tym ? Myślenie o elastyczności w takim przypadku nie ma sensu. Macie wszyscy po trochu racji, ale jak zwykle na tym forum.. eh nie ważne.
Każdy z was mówi o nieco innych przypadkach i podejściach. Najlogiczniejsze jest dla mnie to co pisze Orzeszekk. Dziedziczenie jest użyteczne, przy komplikowaniu się kodu w którym jest ono używane - należy go refaktoryzować w celu stosownia np. Strategii, ale nigdy tych czynności nie należy robić zbyt wcześnie ponieważ elastyczność potrafi niepotrzebnie skomplikować projekt.

A poza tym nie ma wiedzy jedynie prawdziwej, biorąc pod uwagę fakt oszczędzania czasu i nie marnowania go na "kombinatorykę elastyczną" - należy pójść na początku po najmniejszej linii oporu Orzeszka, jeśli zajdzie potrzeba użyć rozwiązania Crozina lub zupełnie innego, bo można ten apsekt zaprogramować na dziesiątki sposobów. Będzie to zależeć od wymagań jakie postawi nam dalszy rozwój aplikacji. Jeśli Crozin na początku zaczniesz wszystko uelastyczniać na "wydaje mi się" - możesz się zakopać w swoich kombinacjach i gdy przyjdzie czas na wdrożenie czegoś nowego okarze się, że tak uelastyczniłeś system, że stał się nieczytelny i trudny w rozwoju. Niekoniecznie to co napisałeś musi być jedynie prawdziwe i poprawne. Znajde Ci 10 sposobów różnych na to jak sprawić aby to rozwiązanie Człowieka było elastyczne i przygotowane na ewentualnie - każdą zmiane - ale takie myślenie nie ma zupełnie sensu, jest alogiczne, bo który sposób wybierzesz ? A jeśli strategia którą wybierzesz okarze się nieużyteczna i błędna to będziesz musiał zmienić większą ilość kodu niż przed wprowadzeniem strategii. Z elastycznością czeka się do ostatniego momentu - nigdy nie robi się tego na samym początku projektowania. Tak podpowiada mi moje doświadczenie.

Zawsze musi istnieć informacja o tym jaka klasa ma być użyta. To wiadome. Teraz od nas zależy kiedy tą informacje wykorzystamy - czy na poziomie kontrolera i tu:

czy na poziomie fabryki, czy innego sposobu jak odrębnej klasy która wybiera nam klasę do zbudowania obiektu na zasadzie strategii. Temat o tyle śliski, że dosyć niejednoznaczny - który sposób wybrać. Sam zawsze mam z tym problemy ale tylko dlatego, że myślę o elastyczności zbyt wcześnie. Zależy to od innych rzeczy, które znajdują się w kodzie. Jeśli wiesz, że będziesz rozszerzać klasę komunikacji dobrze użyć Strategii w tym przypadku jak na moje oko ;-). W switchach nie ma nic złego dopóki nie zaczynają nam przeszkadzać. Dwa case'y w switch to nie tragedia, ja bym sie tym narazie nie przejmował. Nazwij tego switch'a jako funkcje TwinPeaks() i już ;-) .

Pozdrawiam.

Napisane być i może ale niewiadomo jakie i ile mają serwerów + baz danych Jeśli więc idzie o tą gre - zacząłbym od podstaw, potem przepisanie gry może być problematyczne ale nie musi - wsio zależy ot jak leży i jak to zakodujesz. A jeśli chodzi o ZF vs wydajność to bym uciekał jak od ognia.

Pisanie we frameworkach tych znanych mija się z celem jeśli chodzi o osiągnięcie dużej wydajności. Samo PHP nie jest zbyt wydajne, jest jeszcze coś takiego jak HipHop: hiphop - wikipedia - to co zastosowali we Facebook. Ponoć rewelacyjnie przyspiesza działanie PHP.

Czytaj czytaj i jeszcze raz czytaj. Mniej tego z forum, a więcej blogów i książek. Poświęc na samo czytanie tydzień lub dwa. Jeśli przestaniesz programować i przeczytasz przez dwa tygodnie wiele różnych informacji o OOP, wiele Ci się rozjaśni. Skup się również na refaktoryzacji. Jak przerobisz teorię - i popatrzysz na swój kod odrazu powinieneś być w stanie wyciągnąć te fragmenty, które stanowią jakąś odrębność. Spróbuj też pobawić się długopisem i kartką. Wszystko co wpadnie Ci do głowy określaj za pomocą Klas. Jeśli w grze masz Bohatera, Pojazd, Budynek, Trawe, Rzeke, Miecz, Statek kosmiczny, Planete a nawet czynność jak Poruszanie, Predkosc - zrób z nich klasy. Zobaczysz co i jaki ma sens i jak zmieni się sposób wykorzystania tych elementów tylko dlatego że opakowałeś to w nową strukturę. To tylko początek, ale zaczniesz widzieć na czym polega obiektowość. Zapoznaj się też z pojęciem "metafor" w Extreme Programming. Zacznij myśleć abstrakcyjnie - czyli nie myśl o funkcjach substr(), mysql_connect(), ale o wytnijLancuch() polaczMnieZbaza() ... implementacja niskopoziomowa to już pikuś polegający na zajrzeniu do dokumentacji. Naucz się myśleć w oderwaniu od języka programowania - jakiegokolwiek, nabierzesz podstaw myślenia obiektowego.