Comments on: O abstrakcji klas i interfejsów http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/ Pragmatyzm kontrolowany Wed, 28 Dec 2011 11:54:05 +0000 hourly 1 http://wordpress.org/?v=abc By: Lojciec devBlog » Blog Archive » klasy abstrakcyjne a interfejsy http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-44957 Lojciec devBlog » Blog Archive » klasy abstrakcyjne a interfejsy Sun, 07 Feb 2010 17:14:01 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-44957 [...] właściwie są klasa abstrakcyjna i interfejs. Pozwolę sobie tutaj zacytować fragment podobnego artykułu z blogu Splatch’a. (…) trzeba potrafić rozróżnić interfejs od klasy abstrakcyjnej, [...] [...] właściwie są klasa abstrakcyjna i interfejs. Pozwolę sobie tutaj zacytować fragment podobnego artykułu z blogu Splatch’a. (…) trzeba potrafić rozróżnić interfejs od klasy abstrakcyjnej, [...]

]]> By: ActiveY http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-5303 ActiveY Tue, 17 Apr 2007 10:03:21 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-5303 To ja sie przyczepie ... Nie wymieniles kilku istotnych roli obu konstruktow. Jezeli chodzi o klasy abstrakcyjne: Moga zachowywac sie zupelnie tak samo jak interfejsy - definiujac wylacznie metody abstrakcyjne - moga takze definiowac zwykle metody plubliczne, ktore to beda wykonywaly jakas logike operujac na implementacjach metod abstrakcyjnych. Sytuacja: istnieje sobie klasa abstrakcyjna, definiujaca dwie metody: pierwsza metoda jest oznaczona jako "abstract" co powoduje, ze implementacja klasy bedzie pociagala za soba koniecznosc implementacji tejze metody. Druga metoda, publiczna, bedzie wykonywana bezposrednio przez mechanizmy naszej aplikacji/systemu/biblioteki. Ona to bedzie decydowala kiedy i w jaki sposob wykonac metode abstrakcyjna (jakie parametry do niej przekazac) - mozna dlugo wymieniac zastosowania i powody uzycia... Poslugiwanie sie tylko interfejsami niczego nie zalatwia, ba, czasem moze bardzo komplikowac zycie - interfejs moze byc zaimplementowany przez dowolna klase, mozna sie pogubic z separacja odpowiedzialnosci ... Ale co ja tam wiem ;) To ja sie przyczepie …
Nie wymieniles kilku istotnych roli obu konstruktow. Jezeli chodzi o klasy abstrakcyjne:

Moga zachowywac sie zupelnie tak samo jak interfejsy – definiujac wylacznie metody abstrakcyjne – moga takze definiowac zwykle metody plubliczne, ktore to beda wykonywaly jakas logike operujac na implementacjach metod abstrakcyjnych. Sytuacja: istnieje sobie klasa abstrakcyjna, definiujaca dwie metody: pierwsza metoda jest oznaczona jako “abstract” co powoduje, ze implementacja klasy bedzie pociagala za soba koniecznosc implementacji tejze metody. Druga metoda, publiczna, bedzie wykonywana bezposrednio przez mechanizmy naszej aplikacji/systemu/biblioteki. Ona to bedzie decydowala kiedy i w jaki sposob wykonac metode abstrakcyjna (jakie parametry do niej przekazac) – mozna dlugo wymieniac zastosowania i powody uzycia… Poslugiwanie sie tylko interfejsami niczego nie zalatwia, ba, czasem moze bardzo komplikowac zycie – interfejs moze byc zaimplementowany przez dowolna klase, mozna sie pogubic z separacja odpowiedzialnosci … Ale co ja tam wiem ;)

]]> By: TeMPOraL http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-5023 TeMPOraL Thu, 12 Apr 2007 09:48:44 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-5023 Bardzo dobry tekst. Ja od pewnego czasu praktycznie nie tworzę kodu bez interfejsów. Szczególną ich przydatność znalazłem przy pisaniu silnika gry w C++. Design oparty na interfejsach jest tu po prostu magiczny. Raz, pozwala zupełnie oddzielić silnik od platformy - najważniejsze podsystemy (grafika, VFS, dźwięk) implementuje się za interfejsem i nic, poza samą implementacją podsystemu (i punktem ich tworzenia) nie wie o tej implementacji. Dwa, można oddzielić kod silnika od kodu stawianego na niej gry - ponieważ silnik stanowi już zamknięte API, można w ogóle nie przejmować się systemem. Sposób, w jaki takie podejście czyści i porządkuje kod jest wręcz zaskakujący. A debugowanie błędów to sama przyjemność. Język C++ nie robi akurat żadnej różnicy semantycznej między klasą abstrakcyjną a interfejsem - to drugie jest tylko umownym terminem na czysto wirtualną klasę zawierającą jedynie funkcje publiczne. Niemniej różnice w użyciu są ogromne :) Co ciekawe, interfejsy są dostępne nie tylko w językach tak wysokiego poziomu jak C++, Java, PHP. W jakimś artykule na GameDev.NET czytałem kiedyś stwierdzenie - to, że język nie jest Object-Oriented nie powoduje, że kod nie może być Object-Oriented. Osobiście widziałem próby fabrykowania funkcjonalności interfejsów w języku C w kodzie źródłowym gry Quake II - strukturka zawierająca tylko wskaźniki na funkcje (co w praktyce podrabiało mechanizm funkcji wirtualnych) była tworzona w jednym miejscu programu, a następnie przekazywana do innego (głównie między DLL'ami a samym silnikiem). Pozdrawiam! Bardzo dobry tekst. Ja od pewnego czasu praktycznie nie tworzę kodu bez interfejsów. Szczególną ich przydatność znalazłem przy pisaniu silnika gry w C++. Design oparty na interfejsach jest tu po prostu magiczny. Raz, pozwala zupełnie oddzielić silnik od platformy – najważniejsze podsystemy (grafika, VFS, dźwięk) implementuje się za interfejsem i nic, poza samą implementacją podsystemu (i punktem ich tworzenia) nie wie o tej implementacji. Dwa, można oddzielić kod silnika od kodu stawianego na niej gry – ponieważ silnik stanowi już zamknięte API, można w ogóle nie przejmować się systemem.

Sposób, w jaki takie podejście czyści i porządkuje kod jest wręcz zaskakujący. A debugowanie błędów to sama przyjemność.

Język C++ nie robi akurat żadnej różnicy semantycznej między klasą abstrakcyjną a interfejsem – to drugie jest tylko umownym terminem na czysto wirtualną klasę zawierającą jedynie funkcje publiczne. Niemniej różnice w użyciu są ogromne :)

Co ciekawe, interfejsy są dostępne nie tylko w językach tak wysokiego poziomu jak C++, Java, PHP. W jakimś artykule na GameDev.NET czytałem kiedyś stwierdzenie – to, że język nie jest Object-Oriented nie powoduje, że kod nie może być Object-Oriented. Osobiście widziałem próby fabrykowania funkcjonalności interfejsów w języku C w kodzie źródłowym gry Quake II – strukturka zawierająca tylko wskaźniki na funkcje (co w praktyce podrabiało mechanizm funkcji wirtualnych) była tworzona w jednym miejscu programu, a następnie przekazywana do innego (głównie między DLL’ami a samym silnikiem).
Pozdrawiam!

]]> By: Yacoos^ http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-4989 Yacoos^ Wed, 11 Apr 2007 11:00:22 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-4989 Niewspominając juz o tym, ze jedna klasa moze wygodnie implementowac wiele interfejsow, a chcac zrealizowac to samo na klasach abstrakcyjnych trzeba tworzyc wielopoziomowe dziedziczenie. Pozdro! Niewspominając juz o tym, ze jedna klasa moze wygodnie implementowac wiele interfejsow, a chcac zrealizowac to samo na klasach abstrakcyjnych trzeba tworzyc wielopoziomowe dziedziczenie.

Pozdro!

]]> By: kwiateusz http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-4794 kwiateusz Fri, 06 Apr 2007 10:31:54 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-4794 W kodzie na phpfi.com jest błąd w nazwie klasy po której dziedziczy Mysql ;) ale ogólnie dzięki za tą notkę, rozjaśniło mi bardziej sprawę różnicy klas abstrakcyjnych od interfejsów :) W kodzie na phpfi.com jest błąd w nazwie klasy po której dziedziczy Mysql ;) ale ogólnie dzięki za tą notkę, rozjaśniło mi bardziej sprawę różnicy klas abstrakcyjnych od interfejsów :)

]]> By: x^k http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-4744 x^k Thu, 05 Apr 2007 06:28:54 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-4744 Splatch jasne :) ja wiem o tym, ale to nie zmienia faktu, że jednak ktoś tak zrobił m.in. w tej księdze. I to mnie meczy... Czyżby aż tak wielki błąd popełnili ? Postaram się odnaleźć e-booka, żeby nie pozostać gołosłownym :) PS. Tytuł jednak pomyliłem... To chodziło o tą książkę: http://helion.pl/ksiazki/php5ob.htm Splatch jasne :) ja wiem o tym, ale to nie zmienia faktu, że jednak ktoś tak zrobił m.in. w tej księdze. I to mnie meczy… Czyżby aż tak wielki błąd popełnili ? Postaram się odnaleźć e-booka, żeby nie pozostać gołosłownym :)

PS. Tytuł jednak pomyliłem… To chodziło o tą książkę: http://helion.pl/ksiazki/php5ob.htm

]]> By: Łukasz Dywicki http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-4716 Łukasz Dywicki Wed, 04 Apr 2007 18:00:05 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-4716 Interfejs nie może pełnić roli klasy abstrakcyjnej a tym bardziej klasa abstrakcyjna roli interfejsu. To nie to samo! Być może język sprowadza to do podobnej postaci, ale nie zmienia to faktu iż zamienne stosowanie jednego i drugiego to pomyłka. Interfejs to definicja, klasa abstrakcyjna to początek implementacji i w taki sposób powinno to być wykorzystywane. Nie inny. <b>@x^k</b> - widzisz różnicę <a href="http://phpfi.com/223327" rel="nofollow">http://phpfi.com/223327</a>? Interfejs nie może pełnić roli klasy abstrakcyjnej a tym bardziej klasa abstrakcyjna roli interfejsu. To nie to samo! Być może język sprowadza to do podobnej postaci, ale nie zmienia to faktu iż zamienne stosowanie jednego i drugiego to pomyłka. Interfejs to definicja, klasa abstrakcyjna to początek implementacji i w taki sposób powinno to być wykorzystywane. Nie inny.

@x^k – widzisz różnicę http://phpfi.com/223327?

]]> By: x^k http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/comment-page-1/#comment-4699 x^k Wed, 04 Apr 2007 11:23:10 +0000 http://blog.dywicki.pl/2007/04/04/o-abstrakcji-klas-i-interfejsow/#comment-4699 Splatch, a co z takim rozwiązaniem ? http://playme.2adv.pl/?f=inter.php Już kiedyś chwilke o tym rozmawialiśmy... Nawet błąd przez php jest zwracany w sposób indentyczny. Tak jak by php traktowało interfejs jak klase abstrakcyjną :| Coś w tym chyba musi być bo już spotkałem się (AFAIR PHP5: power programming, ale ręki nie dam sobie uciąć) z takim podejściem do tematu. Zaczynam się zastanawiać czy czasami w PHP reprezentacja interfejsów za pomocą _takich_ klas abstrakcyjnych nie będzie w pewnych przypadkach wygodniejsza ? ...kawyyy :) Splatch, a co z takim rozwiązaniem ? http://playme.2adv.pl/?f=inter.php

Już kiedyś chwilke o tym rozmawialiśmy… Nawet błąd przez php jest zwracany w sposób indentyczny. Tak jak by php traktowało interfejs jak klase abstrakcyjną :| Coś w tym chyba musi być bo już spotkałem się (AFAIR PHP5: power programming, ale ręki nie dam sobie uciąć) z takim podejściem do tematu.

Zaczynam się zastanawiać czy czasami w PHP reprezentacja interfejsów za pomocą _takich_ klas abstrakcyjnych nie będzie w pewnych przypadkach wygodniejsza ?

…kawyyy :)

]]>