<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Komentarze do phpgeek</title>
	<atom:link href="http://phpgeek.pl/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://phpgeek.pl</link>
	<description>Z daleka od stereotypów</description>
	<lastBuildDate>Fri, 20 Aug 2010 07:43:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>Skomentuj MongoDB &#8211; Ruch NoSQL przyszłością baz danych?, którego autorem jest Od Informacji do Wiedzy &#187; Archiwum bloga &#187; mongoDB czyli nie relacyjna baza danych</title>
		<link>http://phpgeek.pl/152/mongodb-ruch-nosql-przyszloscia-baz-danych/comment-page-1/#comment-68</link>
		<dc:creator>Od Informacji do Wiedzy &#187; Archiwum bloga &#187; mongoDB czyli nie relacyjna baza danych</dc:creator>
		<pubDate>Fri, 20 Aug 2010 07:43:35 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=152#comment-68</guid>
		<description>[...] - MongoDB – Ruch NoSQL przyszłością baz danych?  [...]</description>
		<content:encoded><![CDATA[<p>[...] &#8211; MongoDB – Ruch NoSQL przyszłością baz danych?  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Dependency Injection Container, którego autorem jest Luneth</title>
		<link>http://phpgeek.pl/112/dependency-injection-container/comment-page-1/#comment-65</link>
		<dc:creator>Luneth</dc:creator>
		<pubDate>Wed, 04 Aug 2010 01:13:11 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=112#comment-65</guid>
		<description>Swoją drogą ten Twój Dependency Injection Container funkcjonuje podobnie jak singleton, przechowuje instancje klas w zmiennej statycznej, plusy są takie, że możemy w tych klasach tworzyć normalne konstruktory, przekazywać parametry do nich.</description>
		<content:encoded><![CDATA[<p>Swoją drogą ten Twój Dependency Injection Container funkcjonuje podobnie jak singleton, przechowuje instancje klas w zmiennej statycznej, plusy są takie, że możemy w tych klasach tworzyć normalne konstruktory, przekazywać parametry do nich.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Design by contract, którego autorem jest Tuner</title>
		<link>http://phpgeek.pl/128/design-by-contract/comment-page-1/#comment-64</link>
		<dc:creator>Tuner</dc:creator>
		<pubDate>Sat, 12 Jun 2010 08:54:26 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=128#comment-64</guid>
		<description>Osobiście uważam, że nazywanie stosowania interfejsów programowaniem kontraktowym to mocna przesada. Gdzie weryfikacja danych wejściowych i wejściowych? Kontrakt w mojej opinii jest nie tylko zapewnieniem, że dany interfejs ma odpowiednią metodę przyjmującą odpowiednie parametry. Narzędzia kontraktu powinny weryfikować poprawność implementacji oraz obiegu danych przy każdym wywołaniu zakontraktowanej funkcji. To tak jakby testy jednostkowe zintegrować z wywołaniem funkcji, których one dotyczą.

PHP posiada narzędzia do stworzenia fundamentów pod programowanie kontraktowe. Wystarczy tylko użyć klas proxy, a można było by pisać:

/**
 * Returns comments amount
 *
 * @assert-in($articleId) is_integer($articleId)
 * @assert-out($result) $result &gt; 0 
 */
public function getCommentsAmount( $articleId )
{
  return rand(0,1000);
}

A jest to tylko podejście z wykorzystaniem metod magicznych. Możemy przecież jawnie deklarować warunki. Można? Można.

Mając sposobność implementacji w PHP programowania kontraktowego wydaje się wręcz żartem to co próbuje nam wepchnąć Zend z nową wersją frameworka. Cieszę się, że starają dobrze poskładać swoje oprogramowanie, ale niech nie udają, że to ma coś wspólnego z programowaniem kontraktowym. Mogą sobie to nazwać jakimś super skrótem DNA (Dobrze Napisana Aplikacja) jeśli mają potrzebę, by sobie szpanować wśród społeczności. Określenie DbC jest nawet znakiem towarym, wiąże się bezpośrednio z Eiffel, wystarczy sprawdzić jak jego twórca określił jego definicję. Nie można sobie dowolnie interpretować wzorców projektowych czy architektur oprogramowania, są jakieś granice. To programowanie nie poezja.

Dzięki za ciekawy wpis. Widzę, że poruszasz interesujące tematy, będę zaglądał częściej. Pozdrawiam!</description>
		<content:encoded><![CDATA[<p>Osobiście uważam, że nazywanie stosowania interfejsów programowaniem kontraktowym to mocna przesada. Gdzie weryfikacja danych wejściowych i wejściowych? Kontrakt w mojej opinii jest nie tylko zapewnieniem, że dany interfejs ma odpowiednią metodę przyjmującą odpowiednie parametry. Narzędzia kontraktu powinny weryfikować poprawność implementacji oraz obiegu danych przy każdym wywołaniu zakontraktowanej funkcji. To tak jakby testy jednostkowe zintegrować z wywołaniem funkcji, których one dotyczą.</p>
<p>PHP posiada narzędzia do stworzenia fundamentów pod programowanie kontraktowe. Wystarczy tylko użyć klas proxy, a można było by pisać:</p>
<p>/**<br />
 * Returns comments amount<br />
 *<br />
 * @assert-in($articleId) is_integer($articleId)<br />
 * @assert-out($result) $result &gt; 0<br />
 */<br />
public function getCommentsAmount( $articleId )<br />
{<br />
  return rand(0,1000);<br />
}</p>
<p>A jest to tylko podejście z wykorzystaniem metod magicznych. Możemy przecież jawnie deklarować warunki. Można? Można.</p>
<p>Mając sposobność implementacji w PHP programowania kontraktowego wydaje się wręcz żartem to co próbuje nam wepchnąć Zend z nową wersją frameworka. Cieszę się, że starają dobrze poskładać swoje oprogramowanie, ale niech nie udają, że to ma coś wspólnego z programowaniem kontraktowym. Mogą sobie to nazwać jakimś super skrótem DNA (Dobrze Napisana Aplikacja) jeśli mają potrzebę, by sobie szpanować wśród społeczności. Określenie DbC jest nawet znakiem towarym, wiąże się bezpośrednio z Eiffel, wystarczy sprawdzić jak jego twórca określił jego definicję. Nie można sobie dowolnie interpretować wzorców projektowych czy architektur oprogramowania, są jakieś granice. To programowanie nie poezja.</p>
<p>Dzięki za ciekawy wpis. Widzę, że poruszasz interesujące tematy, będę zaglądał częściej. Pozdrawiam!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj MongoDB &#8211; Ruch NoSQL przyszłością baz danych?, którego autorem jest jachu</title>
		<link>http://phpgeek.pl/152/mongodb-ruch-nosql-przyszloscia-baz-danych/comment-page-1/#comment-63</link>
		<dc:creator>jachu</dc:creator>
		<pubDate>Sun, 16 May 2010 16:07:01 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=152#comment-63</guid>
		<description>Bardzo ciekawie wygląda, nie miałem jeszcze do czynienia z innymi bazami niż relacyjne.. Czy ktoś to szerzej stosuję?</description>
		<content:encoded><![CDATA[<p>Bardzo ciekawie wygląda, nie miałem jeszcze do czynienia z innymi bazami niż relacyjne.. Czy ktoś to szerzej stosuję?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Design by contract, którego autorem jest Witkacy</title>
		<link>http://phpgeek.pl/128/design-by-contract/comment-page-1/#comment-62</link>
		<dc:creator>Witkacy</dc:creator>
		<pubDate>Mon, 10 May 2010 20:06:34 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=128#comment-62</guid>
		<description>Interfejsy to potężne narzędzie dla wyobraźni. Tak naprawdę interfejsy to tworzenie ogólnej wizji aplikacji. Jak wiadomo - to definiowanie ogólnych powiązań bez implementacji. To myślenie o utrzymaniu spójności między klasami/obiektami i nie wnikaniu w implementacje. Metaforycznie ująłbym to tak: mamy ciało robota, w skład wchodzą kończyny, oczy, słuch, tułów etc. Interfejsy to właśnie ogólne pojęcia jak oczy, uszy, natomiast implementacja to elementy skłądające się na te uszy, oczy i reszte ciała. Projektując aplikacje przy podejściu obiektowym - na początku o wiele łatwiej jest skupić się na ogólnych elementach i nie patrzyć w ogóle na implementację. Projektujemy więc na początku (tak naprawdę ustalając dobre nazewnictwo poszczególnych elementów) ogólne uszy, oczy, ręce, koła, dźwignie, drzwi, etc. nie przejmując się implementacją bo z punktu widzenia &quot;abstrakcyjnego myślenia&quot; w którym jesteśmy na początku projektowania - nie ma to znaczenia. Ważne są nazwy metod i wymiana informacji (rodzajów danych (!) ) między całymi klasami/modułami/zrębami. Natomiast jeśli aplikacja jest naprawdę złożona, praca jaką musimy wykonać - ta niby ogólna praca związana z projektowaniem interfejsów i zarysu klas, ich współpracy etc - staje się również pewnego rodzaju &quot;implementacją&quot; . Grunt w tym żeby nie pogubić się w zarządzaniu danymi z bazy i nie duplikować kodów. Dlatego pomimo projektowania interfejsów chyba istotniejsze moim zdaniem na początku jest opracowanie znormalizowanej bazy danych - a dopiero potem z jej perspektywy projektowanie interfejsów.</description>
		<content:encoded><![CDATA[<p>Interfejsy to potężne narzędzie dla wyobraźni. Tak naprawdę interfejsy to tworzenie ogólnej wizji aplikacji. Jak wiadomo &#8211; to definiowanie ogólnych powiązań bez implementacji. To myślenie o utrzymaniu spójności między klasami/obiektami i nie wnikaniu w implementacje. Metaforycznie ująłbym to tak: mamy ciało robota, w skład wchodzą kończyny, oczy, słuch, tułów etc. Interfejsy to właśnie ogólne pojęcia jak oczy, uszy, natomiast implementacja to elementy skłądające się na te uszy, oczy i reszte ciała. Projektując aplikacje przy podejściu obiektowym &#8211; na początku o wiele łatwiej jest skupić się na ogólnych elementach i nie patrzyć w ogóle na implementację. Projektujemy więc na początku (tak naprawdę ustalając dobre nazewnictwo poszczególnych elementów) ogólne uszy, oczy, ręce, koła, dźwignie, drzwi, etc. nie przejmując się implementacją bo z punktu widzenia &#8222;abstrakcyjnego myślenia&#8221; w którym jesteśmy na początku projektowania &#8211; nie ma to znaczenia. Ważne są nazwy metod i wymiana informacji (rodzajów danych (!) ) między całymi klasami/modułami/zrębami. Natomiast jeśli aplikacja jest naprawdę złożona, praca jaką musimy wykonać &#8211; ta niby ogólna praca związana z projektowaniem interfejsów i zarysu klas, ich współpracy etc &#8211; staje się również pewnego rodzaju &#8222;implementacją&#8221; . Grunt w tym żeby nie pogubić się w zarządzaniu danymi z bazy i nie duplikować kodów. Dlatego pomimo projektowania interfejsów chyba istotniejsze moim zdaniem na początku jest opracowanie znormalizowanej bazy danych &#8211; a dopiero potem z jej perspektywy projektowanie interfejsów.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Nowości PHP 5.3: Przestrzenie nazw, którego autorem jest Grzegorz Świrski</title>
		<link>http://phpgeek.pl/24/nowosci-php-5-3-przestrzenie-nazw/comment-page-1/#comment-61</link>
		<dc:creator>Grzegorz Świrski</dc:creator>
		<pubDate>Tue, 13 Apr 2010 15:57:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sognat.com/?p=24#comment-61</guid>
		<description>Mówisz, masz. :)</description>
		<content:encoded><![CDATA[<p>Mówisz, masz. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Nowości PHP 5.3: Przestrzenie nazw, którego autorem jest Adam</title>
		<link>http://phpgeek.pl/24/nowosci-php-5-3-przestrzenie-nazw/comment-page-1/#comment-60</link>
		<dc:creator>Adam</dc:creator>
		<pubDate>Mon, 12 Apr 2010 08:16:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sognat.com/?p=24#comment-60</guid>
		<description>Szefie, wyrównaj tekst do lewej strony, bo tego się nie da czytać. Widzisz jakie wielkie dziury się robią między wyrazami?</description>
		<content:encoded><![CDATA[<p>Szefie, wyrównaj tekst do lewej strony, bo tego się nie da czytać. Widzisz jakie wielkie dziury się robią między wyrazami?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Czym jest REST?, którego autorem jest szuw</title>
		<link>http://phpgeek.pl/62/czym-jest-rest/comment-page-1/#comment-59</link>
		<dc:creator>szuw</dc:creator>
		<pubDate>Wed, 03 Mar 2010 07:02:23 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=62#comment-59</guid>
		<description>to ma być artykuł techniczny, pisz językiem technicznym</description>
		<content:encoded><![CDATA[<p>to ma być artykuł techniczny, pisz językiem technicznym</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Czym jest REST?, którego autorem jest Grzegorz Świrski</title>
		<link>http://phpgeek.pl/62/czym-jest-rest/comment-page-1/#comment-57</link>
		<dc:creator>Grzegorz Świrski</dc:creator>
		<pubDate>Fri, 29 Jan 2010 12:10:33 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=62#comment-57</guid>
		<description>To tylko przykład, nikt nas nie zmusza do budowania strony w oparciu o bezstanowy model. Jednak zewnętrzne API już jak najbardziej.</description>
		<content:encoded><![CDATA[<p>To tylko przykład, nikt nas nie zmusza do budowania strony w oparciu o bezstanowy model. Jednak zewnętrzne API już jak najbardziej.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Skomentuj Czym jest REST?, którego autorem jest Agares</title>
		<link>http://phpgeek.pl/62/czym-jest-rest/comment-page-1/#comment-56</link>
		<dc:creator>Agares</dc:creator>
		<pubDate>Thu, 28 Jan 2010 18:05:38 +0000</pubDate>
		<guid isPermaLink="false">http://phpgeek.pl/?p=62#comment-56</guid>
		<description>Jak użytkownik wyłączy JavaScript, to całe zamówienie szlak trafi ;].</description>
		<content:encoded><![CDATA[<p>Jak użytkownik wyłączy JavaScript, to całe zamówienie szlak trafi ;].</p>
]]></content:encoded>
	</item>
</channel>
</rss>
