Jaki jest sens tworzenia interfejsu?

pytanie zadane 24 sierpnia 2020 w C# przez assassin Gaduła (3,260 p.)

Hej.

Chciałem was zapytać jaki jest sens używać interfejsu? Wiem jak się go tworzy i implementuje jego metody, ale nie mogę zrozumieć w 100% sensu jego tworzenia. Przez co moje większe, czy też mniejsze aplikacje tracą na jakości kodu, a chciałbym to zmienić.

Czy może ktoś mi to wytłumaczyć łopatologicznie?

Dzięki

3 odpowiedzi

odpowiedź 24 sierpnia 2020 przez Comandeer Guru (601,450 p.)
wybrane 26 sierpnia 2020 przez assassin

Najlepsza

Z interfejsami jest trochę jak z Dzikim Zachodem. Gdy w jakiejś mieścinie rewolwerowiec dostaje odznakę szeryfa, to równocześnie zawiera umowę ze wszystkimi mieszkańcami, że odtąd będzie strzegł porządku. Taki rewolwerowiec nie może już napaść na bank czy wszcząć burdy w saloonie – zamiast tego będzie ścigał rabusiów i pacyfikował co bardziej natarczywych klientów saloonu. A jeśli spróbuje popełnić jakieś przestępstwo, nosząc na piersi dumnie gwiazdę szeryfa, to reszta mieszkańców z satysfakcją go zastrzeli.

Dokładnie tak samo jest z interfejsami. Gdy jakaś klasa dostaje interfejs (odznakę szeryfa), to zobowiązuje się do robienia konkretnych rzeczy. Wiemy, co dana klasa robi i reszta kodu może na niej polegać, oczekując, że dobrze wykona swoje zadanie. Interfejs to nic innego, jak rodzaj dżentelmeńskiej umowy pomiędzy poszczególnymi elementami kodu: "Ja, klasa A, oświadczam, że będę wypełniać obowiązki wynikające z mojego interfejsu i nie będę robić nic więcej". Takie ścisłe określenie przeznaczenia klasy i jej ograniczenie pozwala na tworzenie kodu, który jest o wiele bardziej przewidywalny i łatwiejszy do ogarnięcia (bo od razu widać, która klasa za co odpowiada).

To ma jeszcze jeden plus. Wyobraźmy sobie, że budujemy dom i zatrudniamy robotników. Ale nie wszyscy robotnicy są specjalistami w tym samym. Jeden to mistrz zalewania fundamentów betonem, drugi to wirtuoz hydrauliki, trzeci to prestidigitator elektryki itp. itd. Wciąż jednak wszyscy są robotnikami na tej samej budowie i strażnika przy wejściu na nią nie interesuje, czym dana osoba się zajmuje, po prostu wpuszcza wszystkich robotników. Tak samo można zastosować interfejsy – by stworzyć ogólny zarys funkcjonalności (np. interfejs do obsługi baz danych, z metodami typu connect, find itd.). Natomiast poszczególne klasy, implementujące ten interfejs, będą się specjalizowały w obsłudze konkretnej bazy danych. Naszego kodu nie obchodzi, jaka baza jest używana, po prostu chce dobrać się do danych lub coś zapisać – więc będzie chciał jakiejkolwiek klasy implementującej interfejs od baz danych. Dzięki temu, gdy SQLite stanie się już za małe, można będzie po cichu podmienić je na PostgreSQL, a kod nawet się nie zorientuje. Ot, przyszedł nowy robotnik na budowę.

1	komentarz 24 sierpnia 2020 przez ScriptyChris Mędrzec (190,190 p.) Podoba mi się analogia do szeryfa na Dzikim Zachodzie. :) Czy znasz dobre źródło, które w podobny sposób tłumaczy pozostałe zagadnienia OOP i opisuje wzorce projektowe (coś na kształt https://refactoring.guru/)?

komentarz 24 sierpnia 2020 przez Comandeer Guru (601,450 p.)

Nie bardzo, po prostu to wymyśliłem na poczekaniu.

3	komentarz 24 sierpnia 2020 przez HaKIM Szeryf (87,590 p.) @Comandeer, majstersztyk. Świetnie Ci to wyszło.

komentarz 24 sierpnia 2020 przez HaKIM Szeryf (87,590 p.)

"Ja, klasa A, oświadczam, że będę wypełniać obowiązki wynikające z mojego interfejsu i nie będę robić nic więcej"

Jak rozumiesz "I nie będę robić nic więcej"?

Klasa z maksymalnie jednym interfejsem? Klasa z wieloma interfejsami o różnych pracach, natomiast żadnej pracy pobocznej nie wynikającej z implementowanego interfejsu?

1	komentarz 24 sierpnia 2020 przez Comandeer Guru (601,450 p.) Zdecydowanie to drugie – klasa nie powinna robić nic ponad to, co wynika z jej interfejsu/interfejsów.

komentarz 24 sierpnia 2020 przez ScriptyChris Mędrzec (190,190 p.)

To ja zadam inne pytanie: czy i jaki sens ma więcej niż jedna klasa z tym samym interfejsem, skoro klasa nie powinna robić więcej niż wynika to z implementowanego przez nią interfejsu? Jedyne co przychodzi mi do głowy to, że metody będą miały po prostu inne implementacje, ale będą nazywać się tak samo, przyjmować te same argumenty i zwracać to samo - tylko czy wtedy jest sens żeby miały inne implementacje (wykonywały inny kod wewnątrz)? Przykładem mogą być life cycle hooki we frameworkach?

2	komentarz 24 sierpnia 2020 przez Comandeer Guru (601,450 p.) Podałem przykład na to w poście: interfejs do obsługi bazy danych i klasy dla poszczególnych baz.

komentarz 24 sierpnia 2020 przez HaKIM Szeryf (87,590 p.)

Jeżeli kod wewnętrzny, t.j. implementacja kontraktu, nadanego przez interfejs, opiera się o inne techniki, które to faworyzujemy w różnych sytuacjach bardziej od innych, wtedy jak najbardziej ma sens stworzenie różnych implementacji na każdą z technik wykonywanego zadania.

Jeżeli implementacje skutkują takimi samymi kompromisami we wszystkich lub większości sytuacji to moim zdaniem powinniśmy pomyśleć nad wykarczowaniem jednej z nich. Bardzo rzadko byłem w sytuacji, gdzie to usuwałem implementacje z powodu braków korzyści w różnych sytuacjach nad innym zastosowaniem. O wiele częściej zdarzało mi się to z powodu braku używania danej implementacji.

komentarz 24 sierpnia 2020 przez Comandeer Guru (601,450 p.)

Hm, nie widzę sensu posiadania dwóch klas robiących to samo, a różniących się jedynie szczegółami implementacyjnymi… To bardziej brzmi jak potrzeba refaktoryzacji niż posiadania kilku klas.

Innym przykładem, gdzie dobrze widać różnice, a jest jeden interfejs, może być CAPTCHA. Wszystkie klasy będą implementowały interfejs CAPTCHA, ale jedna będzie obrazkiem, druga minigrą, trzecia będzie dźwiękowa itd. Wszystkie jednak będą zabezpieczać stronę przed spamerami.

komentarz 26 sierpnia 2020 przez assassin Gaduła (3,260 p.)

Dziękuję bardzo za łopatologiczne wytłumaczenie :D

odpowiedź 24 sierpnia 2020 przez Siemił Mądrala (7,380 p.)

Z czasem zrozumiesz. Nie wiem jak to najłatwiej wytłumaczyć. Np: Mam kolekcję 'List<IShape> Shapes'. Interface 'IShape' ma metodę 'Draw'. Gdy mam narysować wszystkie kształty nie obchodzi mnie co jest w tej liście. Jak dostało się do tej listy to ma metodę Draw. Więc w pętli wykonam Shape.Draw() i narysuje wszystki obiekty. Jak będę chciał narysować chmurę to stworzę klasę Cloud : IShipe. Zaimplementuje metodę Draw() i dodam ją do kolekcji. W klasie z kolekcją Shapes żadnej funkcji, żadnego ifa nie muszę dodać/zmienić.

komentarz 26 sierpnia 2020 przez assassin Gaduła (3,260 p.)

Dziękuję za odpowiedź

odpowiedź 24 sierpnia 2020 przez JakSky Stary wyjadacz (14,770 p.)

Kiedyś na Stacku ktoś podał fajny przykład:

How about an analogy: when I was in the Air Force, I went to pilot training and became a USAF (US Air Force) pilot. At that point I wasn't qualified to fly anything, and had to attend aircraft type training. Once I qualified, I was a pilot (Abstract class) and a C-141 pilot (concrete class). At one of my assignments, I was given an additional duty: Safety Officer. Now I was still a pilot and a C-141 pilot, but I also performed Safety Officer duties (I implemented ISafetyOfficer, so to speak). A pilot wasn't required to be a safety officer, other people could have done it as well.

All USAF pilots have to follow certain Air Force-wide regulations, and all C-141 (or F-16, or T-38) pilots 'are' USAF pilots. Anyone can be a safety officer. So, to summarize:

Pilot: abstract class

C-141 Pilot: concrete class

ISafety Officer: interface

added note: this was meant to be an analogy to help explain the concept, not a coding recommendation. See the various comments below, the discussion is interesting.

https://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo