Niestety nie poznałem LINQ na tyle, by móc prowadzić dyskusję z jego wykorzystaniem na takim poziomie abstrakcji Pozostawiam pole osobie, która wie o czym pisze

Gdyby się dłużej zastanowić, to z językami obiektowymi jest tak jak z przeglądarkami internetowymi. Niby robią to samo, ale każdy z nich inaczej implementuje standardy. I pewnie stąd są problemy w odbiorze niektórych zagadnień związanych z obiektówką.

Coś w tym jest.

Abstrahując od wyboru gdzie użyć interfejsu, a gdzie klasy bazowej (i nawiązując do wypowiedzi w tym wątku) to programując języku, który posiada wielokrotne dziedziczenie nie bawiłbym się w interfejsy. Działa to też w drugą stronę - nie zrezygnuje z nich w PHP ze względu na korzyści jakie ze sobą niosą.

Druga sprawa, że wielokrotne dziedziczenie ma tyle samo wrogów, co zwolenników. Ja jestem wrogiem. Interfejsy mimo, że niełatwe w obsłudze mają swoje zalety i trudniej nimi napsuć

Ok, ale akurat typ int dziedziczący po interfejsie dodawanie jest dla mnie poronionym pomysłem i to już tak zupełnie. Pisząc kompilator/interpreter ostatnia rzecz której nam potrzeba to nadmiarowy kod który niczego nam nie daje. Co z tego że int będzie implentował interfejs dodawanie, skoro tak czy inaczej bez względu czy implentuje ten interfejs czy nie musi posiadać metodę dodawanie?



Nie mam pojęcia co to "Refaktorin", zakładam że to czysta literówka i masz na myśli "Refactoring", ale wtedy zupełnie nie wiem co masz na myśli pisząc że jest wolny? I jak to się ma do tematu interfejsów? I co to znaczy że szybsze jest sprawdzanie typu od Refactoring? Serio zdębiałem.


Interface nie zmienia i nie dodaje typu obiektu, z tego co ja się orientuje to obiekt może być tylko jednego typu. Patrząc najprościej obekt "X" nie może być typu INT oraz STRING. Interface tylko i wyłącznie wymusza metody. Jeżeli mamy interface "Zapisz przekazane dane" i mamy 2 klasy które implentują ten interfejs jedną XML (zapisuje w XML), drugą DB (zapisuje w bazie danych), to czy obiekt XML będzie typu XML i "Zapisz przekazane dane" a drugi będzie typu DB i "Zapisz przekazane dane"? Wywracasz mój świat do góry nogami swoimi postami :/

[JAVA] pobierz, plaintext 
interface Moveable{}
interface BlahBlah{}
class Animal{}
class Dog extends Animal implements Moveable, BlahBlah{}
[JAVA] pobierz, plaintext 

Obiekt new Dog() jest typu: Dog, Animal, Moveable, BlahBlah. A.. no i jeszcze Object.
Interface-y mogą stanowić osobny, niezależny typ.

Czy na pewno to ze coś implentuje jakiś interfejs sprawia że obiekt staje się typu klasy której jest obiektem + interfejsów które implentuje? A jeśli klasa pies dziedziczy po ssak, to czy obiekt klasy pies jest typu pies oraz ssak?


Czy na pewno to ze coś implentuje jakiś interfejs sprawia że obiekt staje się typu klasy której jest obiektem + interfejsów które implentuje i klass po których dziedziczy?

Tak, ponieważ Pies dziedzicząc po Ssak otrzymuje jego pełen publiczny interface. Tak więc na obiekcie typu Pies można wykonać dokładnie takie same operacje co na obiekcie Ssak. Różnica jest taka, że pies jako bardziej wyspecjalizowany obiekt może jakąś konkretną metodę realizować inaczej, ale sygnatura tej metody pozostaje niezmienna - tj. interface się nie zmienia. Pies może też realizować metody specyficzne tylko dla Pies, ale mamy 100% że możemy na nim operować jak na Ssak.
Z interface-ami jest dokładnie tak samo.

[PHP] pobierz, plaintext 
$pies instanceof Ssak; //true
[PHP] pobierz, plaintext 

[JAVA] pobierz, plaintext 
void nakarmMnie(Ssak zwierz); //Przekazanie obiektu typu Pies nie spowoduje błędu
 
//Podobnie jak błędu nie spowoduje:
Pies pies = new Pies(); //class Pies extends Ssak
Ssak zwierze = (Ssak) pies;
[JAVA] pobierz, plaintext 

OK, zwracam więc honor, miałem zupełnie inne wyobrażenie o typach.

(odpowiedz na ost. 2 strony postow)

@sztosz



1. Odroznij najpierw moment kompilacji od momentu uruchomienia.
2. W statycznych jezykach (java, c,..) w momencie KOMPILACJI kompilator musi wiedziec czy zmienna "x" ma metode "+". Sprawdzane jest to po typie zmiennej.
Deklarujesz "x" jako 'PlusatorInterface x', ktory to interfejs posiada metode "+" i wszystko jest ok

3. Dla dynamicznych jezykow (Ruby, Python, PHP,...), sprawdzane jest czy OBIEKT! (nie zmienna i jej typ) przypisany do "x" posiada metode "+".
To czy uzylismy tu interfejsu nie ma znaczenia, wazne jest tylko posiadanie metody. Dlatego dla tego typu jezykow intefejsy sa stworzone bardziej w celu
dokumentacji, przedstawienia projektu fragmentu systemu, pokazaniu czemu te N klas ma takie same metody, niz sa potrzebne do uruchomienia kodu.


Skad sie wziely interfejsy - bylo mowione 100 razy - zrezygnowano z wielodziedziczenia, autorzy Javy uzali je za ZLO, i zaproponowali interfejsy (chyba oni byli pierwsi).
No i interfejsy sa konieczne w jezykach javo podobnych, ktora nie jest dynamiczna jak php, ruby, python - w ktorych to interfejsy maja mniejsze znaczeni.



sztosz, nie obraz sie ale poucz sie javy czy c#. Chociazby podstaw bo z tego co widze to posiadasz znajomosc jedynie dynamicznych jezykow, i pewne rzeczy ci trudniej pojac.


Tak.

Najlepszy przykład podał właśnie Crozin. W Thinking in java jest to pięknie pokazane na przykładzie zwierzaków.

Intrefejs określa jakie metody musisz użyć, np jak wyobrażałbyś sobie stworzenie for each dla własnej klasy? Przecież jak dajesz

[JAVA] pobierz, plaintext 
MyClass mc = new MyClass();
for(int i:mc)
{
 
}
[JAVA] pobierz, plaintext 

kompilator musi wiedzieć po czym ma iterować i czy w ogóle może iterować.
implements Iterable i klasa kolejna implements Iterator załatwiają sprawę.

Mi się wydawało zawsze że można iterować po czymkolwiek (w rozumienie obiekcie) co posiada metody do iterowania po tym czymś. Np w rubym, jeśli obiekt ma odpowiednio zaimplentowaną metodę each to można używać jej jak iteratora w "typach wbudowane", z times jest podobnie, czy upto. W pythonie masz np. __iter__()

~dr_bonzo słusznie napisał: "sztosz, nie obraz sie ale poucz sie javy czy c#. Chociazby podstaw bo z tego co widze to posiadasz znajomosc jedynie dynamicznych jezykow, i pewne rzeczy ci trudniej pojac." Muszę się pobawić więcej Javą, wtedy zapewne będę inaczej na to wszystko patrzył

Nasunęła mi się jeszcze jedna myśl, a propos interfejsów (i nie tylko) - mianowicie: "Wymyślanie koła na nowo".
Co prawda w javie piszę dopiero od paru miesięcy, ale zauważyłem, że każde rozwiązanie jest w pewien sposób udokumentowane np. odpowiednim interfejsem/abstraktem etc. Pisząc tam jakąś klasę, nie skupiam się nad tworzeniem całego drzewa począwszy od Object, ale wykorzystuje już to co tam jest, co mi język dostarcza.

W phpie zaś, niby mamy SPL, ale jest ono wg mnie dosyć ubogie. Można też powiedzieć, że ile programistów, tyle rozwiązań dotyczących jednego problemu.