Interfejsy, czy to jest naprawdę do czegoś potrzebne? Opcje

[sztosz]

Mam jedno pytanie: Do czego tak na prawdę mogą się przydać interfejsy w programowaniu? Bo za cholerę nie wiem. Szukam unikalnego zastosowania, którego nie dało by się z powodzeniem zastąpić czymś innym i nie znajduję. Do czego to więc?

[Speedy]

Jeśli chodzi o interfejsy w php, to mogą się one przydać np. do budowania prototypu dla jakiegoś zestawu klas, do wymuszania stworzenia konkretnej metody (lub metod) w różnych klasach, do ujednolicenia lub usystematyzowania wybranego zestawu klas. Implementując interfejs nie zapomnimy o żadnej potrzebnej metodzie. Czasem zdarza się, że jakaś aplikacja ma wiele kontrolerów w postaci klas, które mają bardzo podobną budowę tylko pobierają różne dane i na różny sposób je prezentują. Te kontrolery muszą mieć konkretne metody o konkretnych nazwach, które powielają się każdym z nich, ale zwracają co innego. Za pomocą interfejsu możemy automatycznie zapewnić spójność tych kontrolerów i zapewnić uruchomienie każdego kontrolera tylko w przypadku, gdy posiada wszystkie potrzebne metody.

[wookieb]

Przydają się np do tego jak tworzysz klasy elementów formularza. Chcesz, żeby każda klasa elementu musiała zdefiniować pewne metody, właściwości np getHtml, isValid itd.
Dzięki temu masz pewność, że klasy które implementują ten interfejs, będą posiadały podane metody.

Różnica pomiędzy interfejsem a klasą abstrakcyjną to np taka, że możesz implementować wiele interfejsów a dziedziczyć po jednej klasie.

[Speedy]

Różnica pomiędzy interfejsem a klasą abstrakcyjną to np taka, że możesz implementować wiele interfejsów a dziedziczyć po jednej klasie.

Nie tylko. W klasie abstrakcyjnej można zdefiniować całe ciało metody, a w interfejsie tylko jej prototyp (dostępność, nazwa, parametry).

[sztosz]

Ale to w takim razie sprowadza się do tego że do interfejs nie daje mi żadnej nowej funkcjonalności jaką dawał by mi klasa abstrakcyjna (inna sprawa że klasa abstrakcyjna nie daje mi niczego czego nie dawała by mi "zwykła" klasa). Bo co za różnica czy dziedziczę po x klas i implentuję y interfejsów, skoro mogę dziedziczyć po x+y klas. A tym samym nadal nie widzę realnej potrzeby zastosowania interfejsów.


Oczywiście nie chcę zaczynać dyskusji o wyższości kodowania z użyciem interfejsów nad kodowaniem bez ich użycia, bo już za duży ze mnie chłopczyk na bójki o niczym z piaskownicy.
Oraz oczywiście rozumiem że interfejsy, czy klasy abstrakcyjne pozwalają na uniknięcie pewnych błędów, ale z drugiej strony dobrze opisany kod + testy jednostkowe też na to pozwalają, i też o tym nie chcę rozmawiać.

Chce wiedzieć czy interfejs ma w jakieś unikalne zastosowanie którego gdzie nie da się go zastąpić niczym innym. Bo jak na razie dla mnie interfejs to taka klasa abstrakcyjna bez definicji metod, a klasa abstrakcyjna to taka klasa której obiektu nie można utworzyć i... tyle.

[dr_bonzo]

Bo co za różnica czy dziedziczę po x klas i implentuję y interfejsów, skoro mogę dziedziczyć po x+y klas. A tym samym nadal nie widzę realnej potrzeby zastosowania interfejsów.

Chce wiedzieć czy interfejs ma w jakieś unikalne zastosowanie którego gdzie nie da się go zastąpić niczym innym. Bo jak na razie dla mnie interfejs to taka klasa abstrakcyjna bez definicji metod, a klasa abstrakcyjna to taka klasa której obiektu nie można utworzyć i... tyle.

1. Chodzi o to ze mozesz dziedziczyc TYLKO po 1 klasie (pomijam np C++ gdzie mozesz po wielu, ale w nim nie masz interfejsow, ktore niejako zastepuja wielokrotne dziedziczenie).

2. Uzywasz edytora z podpowiadaniem skladni? Albo pokoduj troche w Javie/C# - wymuszanie okreslania typow podpowi ci po co sa interfejsy.

3.

Oraz oczywiście rozumiem że interfejsy, czy klasy abstrakcyjne pozwalają na uniknięcie pewnych błędów, ale z drugiej strony dobrze opisany kod + testy jednostkowe też na to pozwalają, i też o tym nie chcę rozmawiać.

Tak, bez interfejsow wszytko nadal bedzie dzialac. Interfejsy w php sa wskazowka projektowa: czemu te 5 klas ma takie same metody? co musze zrobic zeby napisac 6ta klase, bo chce zmienic implementacje np. session handlera. W innych jezykach sa tez obejsciem okreslania typow dla zmiennych - bo masz N klas niepolaczonych ze soba, zadna nie dziedziczy po drugiej, ale maja wspolma metode, np validate(), no i jakos musisz okreslic typ przy definiowaniu zmiennej.
Uzywasz: Validator validator; gdzie Validator to nazwa interfejsu z metoda validate(). Dzieki temu kompilator wie jakich metod mozesz uzywac na obiektach przypisanych do tej zmiennej.

[sztosz]

1. Chodzi o to ze mozesz dziedziczyc TYLKO po 1 klasie (pomijam np C++ gdzie mozesz po wielu, ale w nim nie masz interfejsow, ktore niejako zastepuja wielokrotne dziedziczenie).

2. Uzywasz edytora z podpowiadaniem skladni? Albo pokoduj troche w Javie/C# - wymuszanie okreslania typow podpowi ci po co sa interfejsy.

3.
Tak, bez interfejsow wszytko nadal bedzie dzialac. Interfejsy w php sa wskazowka projektowa: czemu te 5 klas ma takie same metody? co musze zrobic zeby napisac 6ta klase, bo chce zmienic implementacje np. session handlera. W innych jezykach sa tez obejsciem okreslania typow dla zmiennych - bo masz N klas niepolaczonych ze soba, zadna nie dziedziczy po drugiej, ale maja wspolma metode, np validate(), no i jakos musisz okreslic typ przy definiowaniu zmiennej.
Uzywasz: Validator validator; gdzie Validator to nazwa interfejsu z metoda validate(). Dzieki temu kompilator wie jakich metod mozesz uzywac na obiektach przypisanych do tej zmiennej.

Ad 1: OD KIEDY mogę dziedziczyć TYLKO po 1 klasie?
Ad 3: Ja nie pytam o konkretny język programowania tylko o teorię, po to temat w Hydeparku. Ale to jest właśnie przykład o który mi chodziło, dziękuję.

[dr_bonzo]

1. A od kiedy mozesz? Na pewno *mozesz* w C++, w Javie nie mozesz, w PHP nie mozesz (http://www.php.net/manual/en/keyword.extends.php ) , w Rubym nie mozesz (tam masz moduly, cos blizej wielodziedziczeniu niz interfejsom), C# - tez nie (googlilem przed chwila)

3.

Ad 3: Ja nie pytam o konkretny język programowania tylko o teorię,

Ciezko mowic o teorii kiedy kazdy jezyk jest inny. Mozemy mowic o interfejsach, kiedy za czasow powstawania C++ ich nie bylo.
Java powstala jako "better c++", pozbyli sie wielodziedziczenia, wprowadzili interfejsy itp.

Ten post edytował dr_bonzo 2.09.2009, 00:28:24

[LBO]

Przede wszystkim interfejsy umożliwiają poprawną modularyzację aplikacji i ułatwiają modelowanie zależności pomiędzy obiektami. Są bardzo przydane przy projektowaniu modeli (domain models).

Pokaże to na prostym przykładzie wyszukiwarki produktów.

[PHP] pobierz, plaintext 
interface IProductSearch
{
  /**
   * Add product to search engine index
   *
   * @throws Exception
   */
  public index(IProduct $product);
 
  /*
   * @return IProduct[] array of products hit by search
   * @throws Exception
   */
  public search(array $product);
}
[PHP] pobierz, plaintext 

Wszyscy wiemy jak wiele jest rozwiązań dotyczących wyszukiwarek, zatem:

[PHP] pobierz, plaintext 
class LuceneProductSearch implements IProductSearch
{
  public index(IProduct $product)
  {
     // tutaj używamy np. Zend_Search_Lucene lub Java Bridge
  }
 
  public search(array $product)
  {
     // tutaj używamy np. Zend_Search_Lucene lub Java Bridge
  }
}
 
// lub
 
class SphinxProductSearch implements IProductSearch
{
  protected $pdo;
 
  public function __construct(PDO $pdo)
  {
     $this->pdo = $pdo;
  }
 
  public index(IProduct $product)
  {
     // Prawdopodobnie nic nie robimy i korzystamy z automatycznego indeksowania Sphinxa
  }
 
  public search(array $product)
  {
     // wysyłamy odpowiednie zapytanie SQL do bazy
  }
}
[PHP] pobierz, plaintext 

Użycie mogłoby wyglądać w ten sposób:

[PHP] pobierz, plaintext 
// Tworzymy i ustawiamy obiekt produktu jak i wyszukiwarki
$product->save($product_search);
// lub
$product->update($product_search);
[PHP] pobierz, plaintext 

W powyższym przykładzie jak krowie na rowie wymodelowaliśmy zależność Produkt-Wyszukiwarka przy zapisywaniu i aktualizacji obiektu. Ta zależność może wyglądać tak:

[PHP] pobierz, plaintext 
// Teoretycznie można użyć ORM obiektu pod
// warunkiem, że implementuje interfejs IProduct
class DatabaseProduct implemnts IProduct
{
  // etc
 
  /**
   * @return boolean    true on success, false otherwise
   */
  public function save(IProductSearch $product_search)
  {
    $this->pdo->beginTransaction();
    try {
 
      // W tym miejscu zapisujemy produkt do bazy danych
 
      $this->setId($this->pdo->lastInsertId());
      $product_search->index($this); // obiekt zapisany, teraz go zaindeksujmy w wyszukiwarce
      $this->pdo->commit();
    } catch(Exception $e) {
      $this->pdo->rollBack();
      return false;
    }
    return true;
  }
}
[PHP] pobierz, plaintext 

Jeżeli do projektu jeszcze nie wybrano mechanizmu wyszukiwania, można by również zaimplementować pusty obiekt NoneProductSearch, który by zwyczajnie nic nie indeksował i wracał pustą tablicę przy wyszukiwaniu.

------------------------------------------------
Cały kłopot z programowaniem na interfejsach - jak również niechęć programistów - tkwi w instancjonowaniu obiektów. Trzeba się trochę nagimnastykować.

1. Operator new

[PHP] pobierz, plaintext 
$product_search = new LuceneProductSearch;
//lub
$product_search = new SphinxProductSearch($this->getContext()->getDatabase()->getDatabaseConnection());
[PHP] pobierz, plaintext 

Zwyczajne tworzenie obiektów już nie wystarcza. Potrzeba czegoś bardziej elastycznego, bo można skończyć (np. przy przesiadce z Lucene na Sphinxa) zmieniając nazwę obiektu wyszukiwarki w każdym miejscu, gdzie się jej używa

2. Wzorce kreacyjne i pochodne

[PHP] pobierz, plaintext 
$product_search = $this->getContext()->getProductSearch();
[PHP] pobierz, plaintext 

Już lepiej. Konfiguracja obiektu odbywa się w jednym miejscu, ale od ilości pisaniny (np. fabryka do każdego obiektu ) można szlak trafić.

[PHP] pobierz, plaintext 
// Dla uproszczenia załóżmy, że ta konkretna implementacja kontekstu jest
// również fabryką modeli ProductSearch
class myContext extends sfContext
{
  // etc
 
  /**
   * @return IProductSearch
   */
  public function getProductSearch()
  {
    return new SphinxProductSearch($this->getDatabaseConnection());
  }
}
[PHP] pobierz, plaintext 

3. Bardziej kompleksowe rozwiązania.

Przykładem takowych są kontenery IoC. Całość tworzenia obiektów jest przekazywana do nich w formie np. wygodnej xmlowej konfiguracji.

[PHP] pobierz, plaintext 
$product_repository = $container>get('ProductRepository');
/* @var $product_repository IProductRepository */
 
$product = $productRepository->getProductById($request->getParameter('id'));
/* @var $product IProduct */
 
$product_search = $container>get('ProductSearch'); // Zwraca odpowiednio skonfigurowane LuceneProductSearch lub SphinxProductSearch
/* @var $product_search IProductSearch */
 
// W tym miejscu ustawiamy nowe wartości obiektu $product
 
$product->update($product_search); // et voila
// lub w zalezności, kto jak podchodzi do repozytoriów
$product_repository->save($product);
[PHP] pobierz, plaintext 

[Cysiaczek]

@sztosz - w OOP jest kilka tematów na temat interfejsów, niemal każdy traktuje o sensie ich istnienia. Są tam wymienione wszystkie zalety i wady stosowania interfejsów, wiec aprawde nie rozumiem, po co kolejny temat o tym samym :/
Przenoszę

[sztosz]

1. A od kiedy mozesz? Na pewno *mozesz* w C++, w Javie nie mozesz, w PHP nie mozesz, w Rubym nie mozesz,C# - tez nie

Ale w Pythonie mogę, w Perlu mogę.

Dziękuję wszystkim za komentarze.

Cysiaczek ma rację, niepotrzebnie zakładałem taki temat. Czytam i czytam i wychodzi na to że Interfejsy nie dają żadnej niezastępowalnej funkcjonalności.

[Crozin]

Czytam i czytam i wychodzi na to że Interfejsy nie dają żadnej niezastępowalnej funkcjonalności.

W PHP podstawowym celem interface-ów jest zagwarantowanie, że to z czym masz do czynienia jest tym czego oczekujesz - przynajmniej w części z której będziesz korzystać.
I takiej funkcjonalności nie dają Ci żadne inne elementy języka.

btw: z wielokrotnym dziedziczeniem nie chodziło o coś takiego:

[PHP] pobierz, plaintext 
class A{}
class B extends A{}
class C extends B{}
[PHP] pobierz, plaintext 

Tylko o

[PHP] pobierz, plaintext 
class A{}
class B{}
class C extends A, B{}
[PHP] pobierz, plaintext 

Taka konstrukcja w PHP jest niemożliwa.

[sztosz]

Mnie fascynuje Python, PHP denerwuje. Do zagwarantowania że to z czym mam do czynienia jest tym czego oczekuję nie są mi potrzebne interfejsy a specyfikacja, dokumentacja raczej. Poza tym mogę zawsze dziedziczyć po klasie abstrakcyjnej, inna sprawa że nie ma klas abstrakcyjnych w Pythonie, ale to też jest banalnie poste do zaimplentowania. Teraz nasuwa się pytanie: Kiedy wyrzucany jest błąd związany z tym że klasa nie poprawnie implementuje jakiś interfejs, w momencie tworzenia obiektu klasy, czy.... no kiedy?

btw: z wielokrotnym dziedziczeniem nie chodziło o coś takiego:

[PHP] pobierz, plaintext 
class A{}
class B extends A{}
class C extends B{}
[PHP] pobierz, plaintext 

Tylko o

[PHP] pobierz, plaintext 
class A{}
class B{}
class C extends A, B{}
[PHP] pobierz, plaintext 

Taka konstrukcja w PHP jest niemożliwa.

Dla mnie wielokrotne dziedziczenie to coś takiego:

[PYTHON] pobierz, plaintext 
class A(object):
    def a(self):
        print 'a'
 
class B(object):
    def b(self):
        print 'b'
 
class C(A, B):
    pass
 
obiekt = C()
obiekt.a()
obiekt.b()
[PYTHON] pobierz, plaintext 

rezultat:

Kod

a
b

I cały czas o tym mówię.

Ten post edytował sztosz 2.09.2009, 14:42:27

[Crozin]

Mnie fascynuje Python, PHP denerwuje.

Mnie też PHP wieloma elementami denerwuje i staram się od niego odejść na rzecz m.in. Javy - ale jest to nadal potężne narzędzie, które oferuje na prawdę wiele.

Do zagwarantowania że to z czym mam do czynienia jest tym czego oczekuję nie są mi potrzebne interfejsy a specyfikacja, dokumentacja raczej.

Dokumentacja dokumentacją, kod kodem.

[PHP] pobierz, plaintext 
<?
class A{
  public function abc(MyInterface $obj){
 
  }
}
[PHP] pobierz, plaintext 

Takie wymuszenie jest dużo wygodniejsze niż patrzenie po dokumentacji. Poza tym ewentualny błąd:

Metoda A:abc() wymaga by pierwszy argument był MyInterface-m

Jest dużo wygodniejszy niż

Nie można wykonać metody def() na obiekcie XXX - linia 123, plik abc

Poza tym mogę zawsze dziedziczyć po klasie abstrakcyjnej

No właśnie klasy abstrakcyjnej nie możesz użyć zawsze... ba! Użycie jej jest możliwe jedynie w podstawowych przypadkach typu:

[PHP] pobierz, plaintext 
<?
 
abstract class Shape{
  abstract public function getSomething();
}
 
class Square extends Shape{
 
}
 
//...
public function doSth(Shape $shape)
[PHP] pobierz, plaintext 

Co w przypadku gdy Square dziedziczy już po czymś? Nie możesz w nieskończoność dziedziczyć, bo w końcu byś sens tego stracił: Zwierzę -> Ssak -> Człowiek - to jak najbardziej ok. Zwierzę -> Porusza się -> Oddycha -> Mówi -> Ssak -> Człowiek? Ssaki są rozwinięciem "mowy"? Z interfaceami jest to logiczne: Zwierzę(porusza się, oddycha, mówi) -> Ssak -> Człowiek.

inna sprawa że nie ma klas abstrakcyjnych w Pythonie, ale to też jest banalnie poste do zaimplentowania.

A w PHP nie ma klas wewnętrznych... ale co to ma do rzeczy?

Kiedy wyrzucany jest błąd związany z tym że klasa nie poprawnie implementuje jakiś interfejs, w momencie tworzenia obiektu klasy, czy.... no kiedy?

W przypadku PHP - sprawdzanie czy dana klasa implementuje wszystkie interface-y wykonywane jest w momencie tworzenia obiektu - ale to w manualu można wyczytać.

Dla mnie wielokrotne dziedziczenie to coś takiego:

W PHP coś takiego jest niemożliwe.

[sztosz]

No i to jest właśnie ten problem którego chciałem uniknąć. Założyłem temat na Hydeparku, a nie w PHP żeby mi nie tłumaczono co można w PHP a czego nie, bo to mnie zupełnie nie interesuje. Chciałem dowiedzieć się czegoś o interfejsów od bardziej doświadczonych forumowiczów, a i tak dowiaduję się "Co mi da używanie interfejsów w PHP". Jeśli zaraz nie padnie stwierdzenie w stylu "A czegoś się spodziewał, to przecież forum PHP!'' to będę zaskoczony.

Z tego tematu wynika że w PHP interfejs jest tylko pomocnikiem by programista widział co musi zaimplentować, natomiast i tak musi dla każdej klasy implementującej dany interfejs napisać ciało metody. Dziedzicząc zaś po kilku klasach (co w PHP jest nie możliwe) nie musimy tego robić, ale nic nie stoi na przeszkodzie przesłaniania metod klas po których dziedziczymy (owszem tu są tez niedogodności, ale tylko jeśli nieuważnie kodujemy).

[PYTHON] pobierz, plaintext 
class Czlowiek(PoruszaSie, Oddycha, Mowi, Ssak, Zwierze):
    pass
[PYTHON] pobierz, plaintext 

I nie potrzeba mi interfejsów.

[Crozin]

Ahh... zapomniałem, że temat miał być ogólny - mój błąd. Przeglądałem przez "Pokaż najnowsze" i nie zwróciłem nawet uwagi na dział.

Wracając do przykładu z królestwem zwierząt. Co wg Ciebie miała by robić (abstrakcyjna) klasa "porusza się"? Przecież człowiek porusza się w zupełnie inny sposób niż bardzo podobna do niego małpa nie wspominając np. o psie czy delfinie (a wszystkie te zwierzęta dziedziczą po: Zwierzę -> Ssak). Tak więc nie ma tutaj po prostu czego dziedziczyć bo każdy z obiektów wykonuje to zupełnie inaczej. Ale z zewnątrz mamy tak jakby ten sam interface, bo każdy z tych wymienionych obiektów potrafi poruszyć się w prawo, w lewo, do przodu oraz do tyłu.
Jeżeli bardzo chciałbyś użyć tutaj dziedziczenia to musiałaby to być abstrakcyjna klasa definiująca jedynie abstrakcyjne metody, a język prog. musiałby umożliwić wielokrotne dziedziczenie. interface natomiast przynosi nam bardzo wygodny mechanizm identyfikacji "możliwości" obiektu:

[PHP] pobierz, plaintext 
//powiedzmy, że jesteśmy wew. jakieś metody "obrony przed zagrożeniem"
if($obj->poziomZycia < 30 && $obj instanceof MozeSiePoruszac){
  $obj->uciekajByleGdzie();
}else{
  $obj->pozegnajSieZZyciem(); //niestety nasz obiekt jest grzybkiem, który nie może uciec
}
[PHP] pobierz, plaintext 

Tak więc nawet w PHP (chociaż ten przykład jest od tego języka dosyć mocno oderwany) interface-y pełnią dużo większą rolę niż tylko "pomocnicza".

Ten post edytował Crozin 2.09.2009, 16:27:54

[sztosz]

O widzisz, i zaczynam poniekąd znajdować zastosowanie dla interfejsu.

[dr_bonzo]

Z tego tematu wynika że w PHP interfejs jest tylko pomocnikiem by programista widział co musi zaimplentować, natomiast i tak musi dla każdej klasy implementującej dany interfejs napisać ciało metody. Dziedzicząc zaś po kilku klasach (co w PHP jest nie możliwe) nie musimy tego robić, ale nic nie stoi na przeszkodzie przesłaniania metod klas po których dziedziczymy (owszem tu są tez niedogodności, ale tylko jeśli nieuważnie kodujemy).

Tak To prawda.
Interfejsy sa obejsciem wielokrotnego dziedziczenia (rozwiazaniem zaproponowanym zamiast W. D.), i ich wada jest to ze nie moga zawierac cial metod - bo tak ich tworcy sobie zalozyli
Pewnie z perspektywy czasu nie jest to najlepsze rozwiazanie, i wielodziedziczenie sie przydaje (dla php, hmm, chyba mielem kilka chwil gdzie bym z niego skorzystal, ale nie jestem w stanie wymienic - o musialem zduplikowac kilka metod w dwoch roznych hierarchiach klas, a takto podziedziczylbym z 3ciej klasy i po problemie).

PHP poniekad wzorowalo sie na javie w OOP. Jednak w Javie oprocz interfejsow masz tez klasy wewnetrzne, ktore to pozwalaja w pewien sposob wykonac wielodziedziczenie, konkretniej - dodac do klasy zbioru metod z cialami, jednoczesnie kozystajac z pojedynczego dziedziczenia - http://www.javaworld.com/javaworld/jw-10-2...4-multiple.html .

[vokiel]

Osobiście dla mnie interfejsy są zasadne w kilku przypadkach:
Pluginy - gdy plugin musi mieć określone metody (instalacja, dodanie do menu w panelu, sprawdzenie wersji, wyswietlenie na stronie, etc). Interfejs wymusza zastosowanie tych metod, dzięki czemu wiem, że nie dołączę pluginu bez instalatora.

Drivery - ostatnio pisałem loggera. Przedstawię na przykładzie:

[PHP] pobierz, plaintext 
<?php
interface logInterface {
    public static function error($err);
    public static function warn($err);
    public static function info($err);
}
 
class logFile implements logInterface {
	public static function error($err){
		// zapis błędu do pliku
	}
	public static function warn($err){
		// zapis ostrzeżenia do pliku
	}
	public static function info($err){
		// zapis informacji do pliku
	}
}
?>
[PHP] pobierz, plaintext 

Każda następna klasa implementująca logInterface musi posiadać te 3 metody. Dzięki temu mogę utworzyć klasę log która będzie przyjmowała obiekty klas implementujących logInterface.
W przypadku zmian, dodaniu innego sterownika logów, użycie będzie zawsze takie samo:

[PHP] pobierz, plaintext 
log::info($err);
[PHP] pobierz, plaintext 

Wystarczy na początku skryptu zmienić sterownik:

[PHP] pobierz, plaintext 
log::addDriver(new logDb());
log::useDriver('logDb');
[PHP] pobierz, plaintext 

I już mogę używać logowania do bazy zamiast do pliku, bez zmian w całym kodzie.

Można to osiągnąć przez użycie klasy abstrakcyjnej. W tym przypadku logowanie do pliku odbywa się zupełnie inaczej niż logowanie do bazy. Zatem klasa abstrakcyjna musiałby mieć tylko zarysy metod, bez ciała - co w rezultacie sprowadza się do interfejsu.

Interfejs dodaje warstwę abstrakcji, którą w przypadku zmian łatwo wymienić nie ingerując w cały kod wykorzystujący dane rozwiązanie.

[sztosz]

@vokiel: Ale do tego żeby to zrobić, nie potrzebujesz ani interfejsu, ani klasy abstrakcyjnej, wystarczy po prostu mieć dane metody w klasie sterownika loggera. Jak na razie wszyscy piszą o tym gdzie można użyć interfejsu, ale ja sam potrafię znaleźć miliony zastosowań dla interfejsu, lecz nie w tym rzecz. Jak na razie wiem, że w językach które nie mogą dziedziczyć po wielu klasach interfejs jest "kulawym"* zastępcą dziedziczenia po wielu klasach. Ale nie widzę nigdzie przykładu gdzie interfejs jest nie do zastąpienia w bardzo prosty sposób, a tego szukam.

Przykład ~Crozin'a z "object x is instance of Class Y" tam gdzie jest dziedziczenie po wielu klasach nie potrzebuje atrybutu, tam gdzie nie ma tego można i chyba nawet lepiej zastąpić to jakimś atrybutem klasy bazowej. Bo "możeChodzić" pasuje mi bardziej jako booleanowski atrybut a nie jakiaś klasa czy interfejs. W konstruktorze grzybka ustawiamy "możeChodzić = False" a mrówki "możeChodzić = True". Ale za daleko wybiegam chyba z myślami poza temat.


___________
*Kulawym ponieważ nie pozwala tworzyć w interfejsie ciała metody. Ale tak to zostało zaprojektowane i nie mnie oceniać czy to źle czy dobrze.