interfejsy to ściema ? Opcje

[Nortonek]

Witam

cały czas nurtuje mnie pytanie i poczucie świadomości że interfejsy to jakaś totalna bzdura,

niby służą one do wielodziedziczenia (dla mnie oznacza to oszczędność czasu i mniej kodu)

ale jakoś nie mogę tego pojąć


pisanie tysięcy linijek kodu zawsze od zera, gdzie tu logika

interfejs A ma 300 metod, interfejs B ma 300 metod, interfejs C ma 300 metod, interfejs D ma 300 metod

i teraz robię 1 klasę ABCD, która implementuje te 4 interfejsy i piszemy w niej 1200 metod od zera

po czym w kolejnej klasie ABCD_v2 chcemy wykorzystać te same metody i niestety ale musimy je napisać znowu od zera jeszcze raz

czy na tym to polega ?

[sowiq]

Skoro masz klasy z 300 metodami, to znaczy, że coś robisz źle już od podstaw To zdecydowanie za dużo funkcjonalności jak na jedną klasę.

Tak na prawdę interfejs ma być ograniczeniem zakładanym na klasy i jednocześnie mechanizmem, który zapewni poprawność napisanej klasy (która go implementuje).

Załóżmy, że robisz bloga. W dobrze zaprojektowanym projekcie masz adapter do operacji na danych (zapis, odczyt). Nie powinno Cię interesować czy zapisuje on do bazy, pliku XML, pliku CSV itp. Masz mieć tylko 3 metody - write, read, find.
Jeśli stworzysz sobie interfejs, który będzie wymuszał implementację tych metod, to na jego podstawie możesz tworzyć różne silniki do operacji na Twoich danych. Jeśli wszystkie będą implementowały ten sam interfejs, to masz pewność że sposób komunikacji z tymi klasami będzie identyczny. Nie będziesz musiał po zmianie zapisu z XML na bazę danych przerabiać połowy swojego kodu.

To tak po krótce

I to nie jest tak, że musisz pisać coś kilka razy. W interfejsie tylko deklarujesz metody, bez ich implementacji.

Ten post edytował sowiq 9.01.2014, 09:30:53

[Nortonek]

... no własnie chodzi mi o to że interfejs jest zbędny, do niczego nie służy a już na pewno nie pomaga w wielodziedziczeniu

w końcu wiem jakie metody chcę mieć w klasie, to po co je mam deklarować w intefejsie

Jeśli piszę powiedzmy 20 klas implementujących 1 i ten sam interfejs to w tych 20 klasach muszę powielić 20 razy zadeklarowane metody, to raczej coś nie tak,

czemu od razu nie pisać sobie 20 klas dziedziczących po 1 klasie z tymi netodami, nie szybciej i nie prościej tak ?

Nie mogę po prostu zrozumieć idei przypisanej do interfejsu, jeśli hodzi o zmniejszenie ilości kodu i przyspieszenie pisania, to interfejs jest dla mnie tego zaprzeczeniem,

czy chodzi w nim tylko o czytelność i przekaz informacji ?

[PrinceOfPersia]

interfejs A ma 300 metod, interfejs B ma 300 metod, interfejs C ma 300 metod, interfejs D ma 300 metod

jak napisał przedmówca - 300 metod to stanowczo za dużo na jedną klasę czy interfejs. Może 3 metody, może 5, 10, może 15...

niby służą one do wielodziedziczenia (dla mnie oznacza to oszczędność czasu i mniej kodu)

Do wielodziedziczenia to służą inne mechanizmy. Interfejsy są bardziej jak "protokoły" do komunikacji między obiektami. Nie mają oszczędzać kodu, bo w ogóle nie definiują kodu, a jedynie nazwy metod, rodzaje argumentów i typ zwracanej wartości.

EDIT: i to jest ich celem. USTANDARDYZOWANIE. Zapewnienie, że obiekty będą się zachowywać zgodnie z interfejsem.

Nie mogę po prostu zrozumieć idei przypisanej do interfejsu, jeśli hodzi o zmniejszenie ilości kodu i przyspieszenie pisania, to interfejs jest dla mnie tego zaprzeczeniem,

no to weź taki przypadek -- fikcyjna biblioteka SuperCaptcha2000 pozwala na skustomizowanie tego w jaki sposób ma być rysowana captcha. W tym celu definiuje interfejs ICaptchaCanvas. Żeby go użyć, musisz odziedziczyć z niego i zaimplementować metody drawLetter, drawBackground.

biblioteka SuperCaptcha później najpierw wywoła twoją metodę drawBackground, żeby narysować tgło, a później będzie wywoływała twoją metodę drawLetter dla każdej litery w słowie.

nie ma tu multidziedziczenia (nie musi być), nie ma tu 300 metod, a jedynie 2. Ale jest korzyść. Bo biblioteka SuperCaptcha2000 dokładnie wie, którą metodę wywołać z jakimi argumentami.

Bez interfejsów/"protokołu" ty byś sobie nazwał metodę po polsku rysujLitere a kolejność argumentów sobie byś zmienił, i biblioteka SuperCaptcha2000 nie miałaby pojęcia jak wywołać twoją funkcję do kustomizowania captcha.

I do tego się tego mniej więcej używa.

Ten post edytował PrinceOfPersia 9.01.2014, 10:59:10

[CuteOne]

Prosty przykład

[PHP] pobierz, plaintext 
interface A {
   public function zrob(Entites\Robota $a, array $b);
}
 
class B implements A {
 
   public function zrob(Entites\Robota $a, array $b) {
 
   }
}
 
 
class C {
 
      public function __construct(A $class) {
 
              $class->zrob($robEntity, $tablica);
      }
}
[PHP] pobierz, plaintext 

1. Mamy pewność, że do konstruktora zostanie przekazany obiekt, który zawiera metodę zrob()
2. Wiemy, że zawsze trzeba jej przekazać encję i tablicę
3. Klasę C nie interesuje jaki obiekt zostanie wstrzyknięty! Byle zawierał interfejs A

[q3trm]

Jeśli piszę powiedzmy 20 klas implementujących 1 i ten sam interfejs to w tych 20 klasach muszę powielić 20 razy zadeklarowane metody, to raczej coś nie tak,

czemu od razu nie pisać sobie 20 klas dziedziczących po 1 klasie z tymi netodami, nie szybciej i nie prościej tak ?

Ja w takim przypadku stosuję abstrakcję, a interfejsy wykorzystuję, gdy jakaś klasa musi posłużyć mi do DI.

Nie mogę po prostu zrozumieć idei przypisanej do interfejsu, jeśli hodzi o zmniejszenie ilości kodu i przyspieszenie pisania, to interfejs jest dla mnie tego zaprzeczeniem,

czy chodzi w nim tylko o czytelność i przekaz informacji ?

Według mnie bardziej o utrzymanie spójności między komponentami systemu, tak jak sowiq napisał.

[Crozin]

Czy PHP mógłby działać w ogóle bez interfejsów? Tak, mógłby, ponieważ język ten działa w nieco inny sposób, niż jakaś Java czy C#, gdzie są one niezbędne.
Po co więc interfejsy? Ponieważ porządkują kod, wprowadzają pewne wymuszenia i ograniczenia oraz dodają nieco statyczności do pisanego kodu, a im bardziej statyczny kod tym więcej narzędzi jest wstanie na nim operować.

Sporo jest też w Google: IDD

[sowiq]

w końcu wiem jakie metody chcę mieć w klasie, to po co je mam deklarować w intefejsie

Ty może i wiesz. Ale inny programista już niekoniecznie. Masz rację, że w małych projektach, pisanych przez tydzień przez jedną osobę i dalej nierozwijanych, nie ma sensu bawić się w bardziej rozbudowane OOP, bo jest to tylko dodawanie sobie roboty. Ale sprawa ma się zupełnie inaczej w przypadku większych aplikacji, nad którymi pracuje kilku programistów jednocześnie.

Zauważ, że języki programowania wcale nie dążą do zmniejszenia liczby linijek kodu. Jest wręcz przeciwnie - dąży się do standaryzacji i pisania (najczęściej dłuższego) kodu, którego części będzie można wykorzystać ponownie w innych projektach. Gdyby tak nie było, to zapewne dalej pisalibyśmy strukturalnie

Załóżmy, że jakiś framework pozwala na podpięcie własnej biblioteki do obsługi bazy danych. Według Ciebie prościej będzie przebijać się przez dokumentację (która pewnie nie zawsze będzie w 100% aktualizowana), czy zaimplementować udostępniony interfejs i pozwolić żeby Twoje IDE wygenerowało Ci wszystkie potrzebne metody z parametrami? (oczywiście zakładając, że metody będą dobrze ponazywane )

Ten post edytował sowiq 9.01.2014, 12:36:29

[em1X]

... no własnie chodzi mi o to że interfejs jest zbędny, do niczego nie służy a już na pewno nie pomaga w wielodziedziczeniu

Może zakończmy temat, napisałeś coś w stylu "po co mi internet, przecież mam książki", a my prowadzimy wywód, żeby Cię przekonać. Takim pisaniem zdradzasz, że kompletnie nie rozumiesz obiektowości i nigdy nie napisałeś poprawnie systemu opartego na jakichś dobrze ugruntowanych praktykach (S.O.L.I.D).

Przesiądź się może na jakiś porządniejszy framework, zf2 albo symfony2? i poczytaj o TDD i dobrych praktykach w programowaniu obiektowym. A może chcesz ćwiczenie? Napisz klasę, która będzie łączyła się z bazą danych i zwracała ostatnio dodany tam rekord, ale pod warunkiem, że nie wiesz co to za baza (plikowa/mysql/nosql/usługa REST).

Ten post edytował em1X 11.01.2014, 10:03:21

[prachwal]

Przesiądź się może na jakiś porządniejszy framework, zf2 albo symfony2? i poczytaj o TDD i dobrych praktykach w programowaniu obiektowym. A może chcesz ćwiczenie? Napisz klasę, która będzie łączyła się z bazą danych i zwracała ostatnio dodany tam rekord, ale pod warunkiem, że nie wiesz co to za baza (plikowa/mysql/nosql/usługa REST).

nie umiesz jeździć rowerem wsiadaj na Honde CBR
buhahahahahahahaha, ale mu życzysz

[em1X]

Dokładnie tak mu życzę.. a zabawa z frameworkiem nie grozi śmiercią, co najwyżej napisze kilka więcej tematów na forum, ale na pewno więcej się nauczy w krótszym czasie, niż pisanie własnego kodu i wywodów jak we wstępie, jak większość użytkowników forum, co widać po zawartości tematów.

[Nortonek]

Dziękuję za tą lekcję, daje mi to do myślenia, przyznaję się tak jak to zauwazył em1X że nie do końca rozumiem OOP zaczynam od pojedyńczych klas i dziedziczenia, aktualnie staram się zagłębić w pisanie MVC (codeigniter) i staram się zrozumieć ideę interfejsów, na zasadzie małych testowych projektów...

[lukasz1985]

Tak, interfejsy to ściema. Bo interfejs, rozumiany jako kontrakt - doskonale definiują klasy abstrakcyjne. Są wyjątki w sytuacjach o których już wiesz, bo sam sobie odpowiedziałeś na pytanie kiedy ich nie używać: wtedy, kiedy implementacja interfejsu w dwóch klasach byłaby taka sama i musiał byś kopiować kod metod wymaganych przez interfejs. A tak obecnie dzieje się bardzo często - bo ludzie nie potrafią logicznie definiować hierarchii dziedziczenia i używać kompozycji.

I nie słuchaj tego biadolenia - że jak ktoś nie rozumie interfejsów to nie potrafi programować obiektowo. Ktoś kto takimi bzdurami sypie sam jest idiotą i powinien się nauczyć programowania obiektowego, gdzie interfejsy są w ogóle nie potrzebne, a ich właściwe wykorzystanie sprowadza się najczęściej do implementacji wywołań zwrotnych w takich językach jak np. Java.

[sowiq]

Ktoś kto takimi bzdurami sypie sam jest idiotą i powinien się nauczyć programowania obiektowego, gdzie interfejsy są w ogóle nie potrzebne

Nikt wcześniej w tym wątku nie napisał do nikogo, że jest idiotą. Wszyscy starają się wytłumaczyć autorowi do czego można użyć interfejsów. Więc z łaski swojej nie zapędzaj się w swoich wypowiedziach obrażając Bogu ducha winnych forumowiczów.

Oprócz interfejsów w PHP są klasy abstrakcyjne, od niedawna traitsy i inne "dziwadła". I wiesz co? Bez nich też da się pisać obiektowo i nikt nikomu na siłę ich nie wciska. Ale ja zakładam, że skoro takie rzeczy pojawiły się w PHP, to czemu ich nie używać? Już nie mówię, że robić to na siłę rozbijając niepotrzebnie swoje klasy, ale np. używając tych wbudowanych w PHP - http://www.php.net/manual/en/reserved.interfaces.php

[edit]
I jeszcze jedno.

Bo interfejs, rozumiany jako kontrakt - doskonale definiują klasy abstrakcyjne.

Problem jest taki, że klasę abstrakcyjną możesz rozszerzyć tylko jedną, a interfejsów zaimplementować kilka jednocześnie.

Ten post edytował sowiq 20.01.2014, 17:35:13

[vonski]

Oprócz interfejsów w PHP są klasy abstrakcyjne, od niedawna traitsy i inne "dziwadła". I wiesz co? Bez nich też da się pisać obiektowo i nikt nikomu na siłę ich nie wciska. Ale ja zakładam, że skoro takie rzeczy pojawiły się w PHP, to czemu ich nie używać?

Dobre podsumowanie tego wątku
Dodam jeszcze, że idąc tym tropem, że "interfejsy to ściema, bo są klasy abstrakcyjne", to można też powiedzieć, że np. private, protected i public też są zbędne bo jest var i domyślnie mogę mieć wszystko public i przecież też wszystko będzie działać. Bo będzie. Chodzi o to, że podobnie jak interfejsy, modyfikatory dostępu wymuszają pewne ograniczenia na programiście, ale jednocześnie, jeśli używane poprawnie, pozwalają uniknąć przypadkowych błędów, czy zaniedbań.

Idąc krok dalej, można powiedzieć, że OOP niewarto się uczyć, bo da się przecież pisać proceduralnie

[pyro]

OOP? PHP? HTML? CSS? Bez sensu. Przecież strony można pisać w Assembly

Ten post edytował pyro 20.01.2014, 18:00:37

[sowiq]

Dokładnie tak. Jak już napisałem wcześniej - jak piszesz aplikację przez tydzień, puszczasz ją na serwer i zapominasz na zawsze, to nie ma sensu zawracać sobie głowy bardziej zaawansowanym OOP niż dziedziczenie. Ale przy pracy w kilkuosobowym zespole czy długim rozwoju swojej aplikacji, używanie tych wszystkich "udziwnień", moim zdaniem, po prostu przyspiesza pracę, ułatwia zrozumienie kodu i (jak np. modyfikatory dostępu) chroni aplikację przed mniej doświadczonymi programistami.

[Daimos]

Mnie urzekł ten fragment wypowiedzi:

w końcu wiem jakie metody chcę mieć w klasie, to po co je mam deklarować w intefejsie

Pracowałeś kiedyś w zespole? Jak będziesz pracował z Tomkiem, to mu powiesz, że mają być takie metody i koniec, ale jak będziesz pracował z:
Tomkiem, Markiem, Jankiem, Piotrkiem, Przemkiem, Stefanem, Michałem, Mariuszem i Anią to zobaczysz, że wtedy reguła "ja to wiem, więc po co..." jest pomyłką.
To takie same podejście jak: "nie komentuje kodu, bo po co, przecież wiem co to"... chyba tego nie trzeba tłumaczyć

[lukasz1985]

Fajnie się usprawiedliwiacie. Tylko te wasze teorie to można sobie za przeproszeniem "wsadzić" - konfrontując to z faktami. Takie gadanie: "nie wiem jak to poskładać, nie wiem jak mam stworzyć plugin, a to niech sobie będzie interfejs".

Już pisałem o tym w innym wątku - łamiecie zasadę pojedynczej odpowiedzialnści stosując interfejsy tak jak stosujecie i prowadzicie do duplikacji kodu. A takie gadanie: że w programowaniu zmierza się do standaryzacji też nic warte nie jest. Bo kod ma mieć czystą i przejrzystą strukture przede wszystkim poprzez to można tworzyć klasy, które można rozszerzać i nikt tutaj nie potrzebuje interfejsów!

Takie modne gadanie, powtarzacie jak małpy, i czytacie bezkrytycznie to co wam podają, a programowanie jak było tak jest kaleczone wciąż.

Jakby ktoś chciał zgłębić temat dlaczego łamie zasadę pojedynczej odpowiedzialności (kluczowej zasady dla utrzymywania zrozumiałego kodu) to zapraszam: http://devmatrix.wordpress.com/2014/01/04/...ava-interfaces/ (już ten link wrzucałem 100 razy).

[pyro]

@lukasz1985, radzę się zapoznać z różnicami pomiędzy klasami, a interfesjami, bo osobiście nie widzę zastosowania tego co piszesz (ani posta na blogu) do postów następujących po Twoim ostatnim. W skrócie - gadasz od rzeczy.