"Program do interfejsu". Co to znaczy? [duplikat]

Interfejs jest zbiorem powiązanych metod, które zawierają tylko sygnatury tych metod-a nie rzeczywistą implementację.
Jeśli klasa implementuje interfejs (class Car implements IDrivable), musi dostarczyć kod dla wszystkich sygnatur zdefiniowanych w interfejsie.

Przykład podstawowy:
Musisz klasy samochodu i roweru. Oba implementują interfejs IDrivable:

interface IDrivable 
{
    void accelerate();
    void brake();      
}

class Car implements IDrivable 
{
   void accelerate()
   { System.out.println("Vroom"); }

   void brake()
   { System.out.println("Queeeeek");}
}

class Bike implements IDrivable 
{
   void accelerate()
   { System.out.println("Rattle, Rattle, ..."); }

   void brake()
   { System.out.println("..."); }
}

Teraz Załóżmy, że masz zbiór obiektów, które są wszystkie "drivable" (ich klasy implementują IDrivable):

List<IDrivable> vehicleList = new ArrayList<IDrivable>();
list.add(new Car());
list.add(new Car());
list.add(new Bike());
list.add(new Car());
list.add(new Bike());
list.add(new Bike());

Jeśli chcesz teraz zapętlić tę kolekcję, możesz polegać na tym, że każdy obiekt w tej kolekcji implementuje accelerate():

for(IDrivable vehicle: vehicleList) 
{
  vehicle.accelerate(); //this could be a bike or a car, or anything that implements IDrivable
}

Wywołując tę metodę interfejsu, nie programujesz do implementacji, ale do interfejsu - kontraktu, który zapewnia, że obiekt wywołania implementuje określoną funkcjonalność.
To samo zachowanie można osiągnąć za pomocą dziedziczenia, ale wywodzącego się ze wspólnej klasy bazowej skutkuje ciasnym połączeniem, którego można uniknąć za pomocą interfejsów.

Polimorfizm zależy od programowania interfejsu, a nie implementacji.

Są dwie korzyści z manipulowania obiektami wyłącznie pod względem interfejsu zdefiniowanego przez klasy abstrakcyjne:

1. klienci pozostają nieświadomi specyficznych typów obiektów, których używają, o ile obiekty przylegają do interfejsu, którego oczekują klienci.
2. klienci pozostają nieświadomi klas implementujących te obiekty. Klienci wiedzą tylko o klasie abstrakcyjnej(klasach) definiującej interfejs.

To tak znacznie zmniejsza zależności implementacji między podsystemami, że prowadzi do tej zasady programowania do interfejsu.

Zobacz wzór metody Fabrycznej {[14] } dla dalszego rozumowania tego projektu.

Zobacz Też: Wzór Fabryczny. Kiedy stosować metody fabryczne?

Prawdziwe przykłady są applenty. Jeden z nich:

Dla JDBC, używasz interfejsu java.sql.Connection. Jednak każdy sterownik JDBC dostarcza własną implementację Connection. Nie musisz nic wiedzieć o konkretnej implementacji, ponieważ jest zgodna z interfejsem Connection.

Kolejny pochodzi z java collections framework. Istnieje interfejs java.util.Collection, który definiuje size, add i remove metody (m.in. Możesz więc używać wszystkich typów Kolekcje zamiennie . Załóżmy, że masz:

public float calculateCoefficient(Collection collection) {
    return collection.size() * something / somethingElse;
}

I dwie inne metody, które odwołują się do tej. Jedna z innych metod używa LinkedList, ponieważ jest bardziej efektywna dla swoich celów, a druga używa TreeSet.

Ponieważ zarówno LinkedList, jak i TreeSet implementują interfejs Collection, można użyć tylko jednej metody do obliczenia współczynnika. Nie ma potrzeby powielania kodu.

I tu pojawia się" program do interfejsu " - nie dbaj o to, jak dokładnie zaimplementowana jest metoda size(), wiesz, że powinna zwracać rozmiar kolekcji - tzn. masz zaprogramowany interfejs Collection, a nie w szczególności LinkedList i TreeSet.

Ale radzę znaleźć lekturę-być może książkę ( na przykład" Thinking in Java") - w której pojęcie jest szczegółowo wyjaśnione.

Każdy obiekt ma odsłonięty interfejs. Kolekcja posiada Add, Remove, At, itd. Gniazdo może mieć Send, Receive, Close i tak dalej.

Każdy obiekt, do którego można uzyskać odniesienie, ma konkretną implementację tych interfejsów.

Obie te rzeczy są oczywiste, jednak to, co jest nieco mniej oczywiste...

Twój kod nie powinien polegać na szczegółach implementacji obiektu, tylko na jego opublikowanym interfejsie.

Jeśli weźmiesz go do ekstremum, kodowałbyś tylko przeciwko Collection<T> i tak dalej (zamiast ArrayList<T>). Bardziej praktycznie, po prostu upewnij się, że możesz zamienić się czymś identycznym koncepcyjnie bez łamania kodu.

Aby uzyskać przykład Collection<T>: masz zbiór czegoś, używasz ArrayList<T>, ponieważ dlaczego nie . Powinieneś się upewnić, że Twój Kod się nie zepsuje, jeśli, powiedzmy, w przyszłości użyjesz LinkedList<T>.

Zasadniczo oznacza to, że jedyną częścią biblioteki, na której będziesz korzystać, jest jej API (Application programming interface) i że nie powinieneś opierać swojej aplikacji na konkretnej implementacji biblioteki.

Np. Przypuszczalnie masz bibliotekę, która daje Ci stack. Zajęcia dają Ci kilka metod. Powiedzmy push, pop, isempty i top. Powinieneś napisać swoją aplikację opierając się tylko na nich. Jednym ze sposobów na naruszenie tego byłoby Podglądanie wewnątrz i dowiedzieć się, że stos jest zaimplementowany przy użyciu tablicy pewnego rodzaju tak, że jeśli pop z pustego stosu, można dostać jakiś rodzaj wyjątku indeks i następnie złapać to zamiast polegać na metodzie isempty, które zapewnia Klasa. Pierwsze podejście zawiedzie, jeśli dostawca biblioteki przełączy się z użycia tablicy na użycie jakiejś listy, podczas gdy ta druga nadal będzie działać, zakładając, że jego API nadal będzie działać.

"Programowanie do interfejsu" dzieje się, gdy używasz bibliotek, innego kodu, od którego zależy twój własny kod. Następnie, sposób, w jaki inny kod przedstawia się Tobie, nazwy metod, ich parametry, wartości zwrotne itp. składają się na interfejs , do którego musisz zaprogramować. Więc chodzi o to, jak używasz kodu innych firm.

Oznacza to również, że nie musisz dbać o wewnętrzne elementy kodu, od których zależą, dopóki interfejs pozostaje taki sam, Twój kod jest bezpieczny (cóż, bardziej lub mniej...)

Technicznie istnieją drobniejsze szczegóły, jak na przykład pojęcia językowe zwane "interfejsami" w Javie.

Jeśli chcesz dowiedzieć się więcej, możesz zapytać, co oznacza "implementacja interfejsu"...

Myślę, że to jedna z mantr Ericha Gamma. Nie mogę znaleźć, Kiedy pierwszy raz to opisał( przed książką GOF), ale można to zobaczyć w wywiadzie na: http://www.artima.com/lejava/articles/designprinciples.html