Praktyka: klasy i interfejsy

pytanie zadane 2 grudnia 2018 w Java przez itcloud Gaduła (3,380 p.)

Żaden kurs tego nie tłumaczy a skupia się na teorii i wałkuje w kółko te same tematy typu: czym jest klasa, czym jest interfejs i jakie różnice między nimi i koniec.

A jak wygląda praktyka?

Dla mnie klasa to zbiór metod i właściwości. Kluczowe są tutaj dla mnie METODY, konkretne zapisy całej logiki, czyli jak dana funkcja ma działać!!! Konkretny kod, prawda?

Interfejs to dla mnie tylko nazwy, nazwy metod czyli jeśli impltementuję taki interfejs, to NIE MAM LOGIKI jeszcze a mam tylko informację, z jakich NAZW funkcji mogę korzystać.

Chyba że ja czegoś nie rozumiem ? Może te nazwy to też konkretne już mechanizmy które się w tych nazwanych metodach kryją?

Bo często jest zapis:

Interfejs x = new Konstruktor_klasy();

a np. jak ktoś tworzy interfejs:

interface{

void show();

}

to daje mi do zrozumienia, że jak implementuję ten interfejs to mam u siebie mieć metodę(funkcję) show().

Ale gdzie ta logika od kogoś kto wcześniej taką metodę SHOW napisał ???? Bo w samym interfejsie PRZECIEŻ TEGO NIE MA!!!!

2 odpowiedzi

odpowiedź 2 grudnia 2018 przez adrian17 Ekspert (344,860 p.)

Ale gdzie ta logika od kogoś kto wcześniej taką metodę SHOW napisał ???? Bo w samym interfejsie PRZECIEŻ TEGO NIE MA!!!!

Nie musi istnieć.

Raczej głównym użyciem interfejsów jest w argumentach metod:

interface Showable { void Show(); }
void SomeMethod(Showable item) {...}

Wtedy Showable pełni rolę prostego kontraktu: możesz przekazać do SomeMethod dowolną rzecz, pod warunkiem, że implementuje Showable (więc musi posiadać metodę Show()).

Ale gdzie ta logika od kogoś kto wcześniej taką metodę SHOW napisał ????

Niekoczniecznie. Jeśli na przykład używasz bibliotekę z metodą SomeMethod i interfejsem Showable, możliwe że nie istnieje ani jedna implementacja tego interfejsu - biblioteka może założyć, że tylko użytkownik biblioteki będzie implementował interfejs dla swoich klas.

komentarz 2 grudnia 2018 przez itcloud Gaduła (3,380 p.)

Czyli to nie jest tak jak nas uczą weszelkie kursy od podstaw, że implementując interfejs mam pamiętać o tym, tzn. nawet sam kompilator mi przypomni, ze mam posiadać metodę taką a taką, nawet jak będzie ona NIC NIE ROBIĆ ?

Bo przy klasach to ja widzę sens, że mam dziedziczyć klasę bo dzięki temu mam pewne mechanizmy do wykorzystania (nie muszę wywarzać otwartych drzwi), ew. klasę rozszerzam.

Jeśli mnie nie rozumiesz, to może posłużę się analogią do php: tam mogłem korzystać z funkcji, które ktoś napisał, z bibliotek, dawałem na początku skryptu include(..) i już.

W javie jak mowa o interfejsach to się gubię, bo co dzięki nim tak naprawdę zyskuję to w teorii wiem, że to kontrakty bla bla bla ale jak widzę korzystanie np. z kolekcji, list, to tam często po lewej stronie, jako typ referencji podaje się właśnie ten interfejs do diaska....

komentarz 2 grudnia 2018 przez mbabane Szeryf (79,280 p.)

tzn. nawet sam kompilator mi przypomni, ze mam posiadać metodę taką a taką, nawet jak będzie ona NIC NIE ROBIĆ ?

Wiesz, że możesz to sobie po testować?

Zapisz to, uruchom program i zobacz co będzie się dziać.

interfejs w programowaniu obiektowym oznacza zachowanie (publiczne) obiektu. Wiele interfejsów ma końcówkę able, tłumacząc to na polski oznacza to zdolny - czyli obiekt jest zdolny do czegoś np. AutoClosable - obiekt zdolny do automatycznego zamknięcia w konstrukcji try-with-resources.

odpowiedź 2 grudnia 2018 przez RafalS VIP (122,820 p.)
edycja 2 grudnia 2018 przez RafalS

Po pierwsze - spokojnie :D

Zmienna typu interfejsu moze przechowywać rozne obiekty klas implementujacych ten interfejs. To czesc polimorfizmu. Podstawy OOP.

Rola interfejsu to wyrazenie pewnego kontraktu. Interfejs to zbior metod publicznych, których implementacji wymagamy od klas implementujacych interfejs.

Pisząc funkcje ktora przyjmuje jakis interfejs jako argument mowimy, ze wymagamy od obiektow przekazywanych aby mialy zaimplementowane dane metody.

Gdybys typ argumentu byl konkretną klasa mógłbyś przeslac tylko obiekty tej klasy i jej pochodne. Przyklad:

void dodaj5(ArrayList<Integer> list){
   list.add(5);
}

Wymagamy arraylisty a wykorzystujemy jedynie fakt ze do tej listy można dodac integer, wiec nic nie stoi na przeszkodzie zeby podac tam inna liste np LiknedList, wiec zmieniamy typ na interfejs:

List<Integer>

Ale moment przeciez do kazdej kolekcji intow da sie dodac 5, wiec czemu sie ograniczac, moze kiedys będziemy chcieieli dodać 5 do HashSet'u

void dodaj5(Collection<Integer> collection){
   collection.add(5);
}

To samo tyczy sie innych klas. Od walidatora czegos wymagamy jedynie zeby potrafil zwalidowac to cos czyli zeby mial metode:

bool isValid(Cos cos);

To wymaganie wyrazamy w postaci interfejsu.

Pokaż 9 poprzednich komentarzy

komentarz 3 grudnia 2018 przez mbabane Szeryf (79,280 p.)

Interfejs logicznie rzecz biorąc wykorzystywany jest do tego by łatwo podmienić implementacje, z której coś korzysta.

Na przykładzie tego List<E> -> ArrayList i LinkedList te dwie klasy i różnią się od siebie diametralnie w działaniu. AL to jest typowa tablica dokładnie taka jak zadeklarowana w sposób ręczny, dostarcza tylko wysoce wydajne rzeczy, które robią ze zwykłej tablicy tablice dynamiczną (czyli zmieniającą swój rozmiar w trakcie działania programu).

LinkedList to jest lista dwukierunkowa.

I teraz robiąc tak:

//SomeClass posiada konstruktor, który przyjmuje List)
 
SomeClass sc = new SomeClass(new ArrayList<>());  //korzystanie z AL
 
sc = new SomeClass(new LinkedList<>()); //cyk zmieniam na LinkedList 
//bez głębokiej ingerencji w kod SomeClass, a własciwie to nawet nie trzeba tam zagladac

Diametralnie zmieniasz sposób w jaki przechowywane są dane w klasie SomeClass. Jednak dzięki zastosowaniu interfejsu sposób użycia tych konkretnych klas jest identyczny - mówimy tutaj tylko i wyłącznie o kodzie źródłowym, zapisanym przez programistę - bo program będzie działał zupełnie inaczej dla AL, a inaczej dla LL.

Poczytaj jeszcze o dwóch rzeczach mianowicie czym jest abstrakcji i hermetyzacja (chociaż tak po prawdzie abstrakcja to jest hermetyzacja). (Jeśli chodzi o abstrakcje nie mam tutaj na myśli klas abstract, tylko abstrakcję w kontekście programowania obiektowego).

komentarz 3 grudnia 2018 przez itcloud Gaduła (3,380 p.)

poczytam o tej abstrakcji, rozumiem też co napisałeś że można zmienić w locie sposób implementacji, zamienić np. jsona na jakieś inny http request itd. ale tego już nie kumam:

Diametralnie zmieniasz sposób w jaki przechowywane są dane w klasie SomeClass.

mozesz to napisać inaczej, tak żeby zrozumiała Twoja druga połówka która zetknęła się tylko na chwilę z programowaniem na studiach ?

komentarz 4 grudnia 2018 przez mbabane Szeryf (79,280 p.)

Dobra. Taka sytuacja. Jest kierowca samochodu. Zakładamy, że każdy samochód ma kierownice, pedały i lewarek do zmiany biegów. Kierowca żeby móc jechać samochodem potrzebuje tych trzech rzeczy - inaczej może stwierdzić, że samochodem nie umie jeździć.

Teraz mamy dwa samochody, maluch i ferrari f60. W obu samochodach sterowanie jest identyczne, aby przyspieszyć trzeba dodać gazu, aby skręcać trzeba ruszać odpowiednio kierownicą, biegi zmienia się w taki sam sposób sprzęgło plus ruch lewarkiem itd. Nie ważne czy jest to maluch czy ferrari w obu te czynności wykonuje się w ten sam sposób.

Z punktu widzenia obsługi pojazdu oba niczym się nie różnią, jednak w samej jeździe już diametralnie.

Ferrari jest szybsze, lepiej wchodzi w zakręty, ale jest dwuosobowe i stosunkowo duże co utrudnia jazdę po mieście.

Maluch gorzej przyspiesza, jest toporny w prowadzeniu jednak jest mniejszy i wygodniej się nim poruszać po mieście.

I teraz dzięki temu, że kierowca umie obsługiwać samochód to tak na prawdę umie jeździć niemal każdym rodzajem auta i w zależności od sytuacji może bardzo łatwo zmienić typ pojazdu np. na szybszy i większy żeby wygodniej podróżować na długich dystansach, albo mały i ekonomiczny aby sprawnie poruszać się po mieście.

Samochód to interfejs. Maluch i Ferrari to implementacje interfejsu - konkretne klasy. Stosując interfejs nie trzeba uczyć, czegoś co z niego korzysta, jak ma używać konkretnej implementacji.

komentarz 4 grudnia 2018 przez itcloud Gaduła (3,380 p.)

Czyli implementacje interfejsu (tego typu interfejsowego) to tak naprawdę to co na prawo, ten konstruktor klasy? Czyli te klasy muszą w danym momencie mieć zaimplementowane dane metody, o których wyraźnie mówi interfejs, czyli defacto przy deklaracji takich klas na pewno pojawia się słówko IMPLEMENTS interfejs (gdzie interfejs to własnie ten typ zmiennej jak niżej:)

Samochod zmienna = new Ferari(); //klasa Ferrari implementuje interfejs samochod, czyli moze miec mnostwo metod ale na pewno te ktorych wymaga Samochod ?

A jak to się ma w końcu do tego przekazywania w argumentach?

komentarz 5 grudnia 2018 przez mbabane Szeryf (79,280 p.)

Ferrari implementuje interfejs samochod, czyli moze miec mnostwo metod ale na pewno te ktorych wymaga Samochod ?

Tak, to jest defacto wymagane przez samą Javę jak coś implementuje interfejs i nie ma wszystkich metod to nastepuje blad kompilacji.

A jak to się ma w końcu do tego przekazywania w argumentach?

Deklarujac ze metoda/konstruktor przyjmuje typ interfejsowy jest ona jak ten kierowca. Kierwocy jest obojetne czy dostaje ferrai czy malucha, z jego punktu widzenia samochod ma miec kierownice, pedaly i lewarek do biegów.

Po programujesz wiecej to to zrozumiesz.