Interfejsy

I nterfejs w rozumieniu jakie za chwilę poznamy może się w pierwszej kolejności mylić z pojęciem interfejsu użytkownika, czyli graficznym dostępem do różnych funkcji programu. W naszym przypadku będzie do szkielet, albo bardziej szczegółowo wymóg jaki będą musiały spełniać klasy implementujące nasz interfejs.

Składnia interfejsu jest następująca:

[specyfikator_dostępu] interface nazwa_interfejsu {
 	elementy_interfejsu...
 }

Przykładowo wyobraźmy sobie interfejs pojazd:

public interface Pojazd {
 	public void jazda(int predkosc);
 	public void stop();
 }

Jak widać dziwne jest w nim to, że posiada dwie metody typu void: jazda() i stop() , ale jak widać nie posiadają one żadnej implementacji, ani nawet nawiasów klamrowych. Tak jak powiedzieliśmy wcześniej, interfejs to kontrakt, który mówi co klasa implementująca może robić, ale nie jak ma to robić.

W naszym przykładzie łatwo sobie wyobrazić klasy Samochód i Rower - obie przedstawiają pojazdy, jednak znacznie się różniące i posiadające jedynie wspólne cechy w zakresie poruszania się (no i może paru innych, ale nie wnikajmy w szczegóły). Jeśli klasy Samochód i Rower będą implementowały interfejs pojazd to będziemy pewni, że będą one mogły się poruszać i zatrzymywać, dzięki metodom jazda() i stop().

public class Samochod implements Pojazd {
 	@Override
 	public void jazda(int predkosc) { }
 
 	@Override
 	public void stop() { }
 
 	public void drift() { }
 }

public class Rower implements Pojazd {
 	@Override
 	public void jazda(int predkosc) { }
 
 	@Override
 	public void stop() { }
 
 	public double skok() { }
 }

Jak widać nasze klasy implementując interfejs Pojazd muszą implementować jego metody (pomocna jest tutaj adnotacja @Override). Nie jest jednak powiedziane, że nie mogą również posiadać własnych dodatkowych metod specyficznych tylko dla siebie, jak na przykład skok() określająca wysokość na jaką skoczyliśmy na rowerze, czy drift() wprawiająca samochód w poślizg. Dodawanie własnych metod nie jest jednak dobrym podejściem, ponieważ tracimy w ten sposób nieco możliwości jakie niesie ze sobą polimorfizm - aby móc korzystać z metod, których nie ma w interfejsie zarówno typ referencji jak i typ obiektu muszą być zgodne - użycie interfejsu wydaje się wtedy zbędne.

Wszystkie metody interfejsu są domyślnie publiczne i abstrakcyjne, nie jest więc konieczne dopisywanie przed nimi tych słów kluczowych, jeśli o tym zapomnimy, nic się nie stanie.

Wszystkie pola interfejsu muszą być zadeklarowane jako publiczne, statyczne i finalne, czyli innymi słowy, w interfejsie możemy także umieszczać stałe pola. Nie muszą być jednak oznaczone słowami final i static, podobnie jak w przypadku metod są one tam dodawane automatycznie

Inne wymagania co do interfejsów w skrócie:

• Interfejs musi być utworzony przy użyciu słowa kluczowego interface

• Interfejsy mogą być wykorzystywane polimorficznie, tzn można ich używać jako typu ogólniejszego klas, które go implementują, poprawne zapisy na podstawie powyższych przykładów to:

Pojazd rower = new Rower();
 Pojazd samochod = new Samochod();

• Interfejs może rozszerzać (extends) tylko interfejsy (nawet kilka, co w przypadku klas jest zabronione)

• Metody interfejsu nie mogą być zadeklarowane jako statyczne

To co ważne, w Javie niedozwolone jest dziedziczenie wielokrotne, jednak jak najbardziej poprawne jest implementowanie wielu interfejsów, przydatność tego rozwiązania zobaczymy w szczególności w przypadku programowania aplikacji z graficznym interfejsem użytkownika, gdzie dodatkowo będziemy obsługiwali zdarzenia generowane przez mysz, lub klawiaturę.