Was ist Schnittstellenprogrammierung? Lass uns Architekt spielen

Vielleicht haben Sie schon einmal gehört, dass es so etwas wie „Schnittstellenprogrammierung“ gibt. Es ist Zeit, dies besser kennenzulernen. Es wird wenig Text und viel Code (ohne Logik) geben. Ich konnte nicht herausfinden, wann die ersten Schnittstellen erschienen. Es ist wahrscheinlich sehr lange her und das Internet hat es vergessen. Ohnehin. Die Idee der Schnittstelle ist einfach: Beschreiben Sie, was wir tun werden, ohne auf Details einzugehen. Diese. Es kommt nicht darauf an, wie du es tust, sondern darauf, was du tust. Aber nachdem ich diesen Artikel geschrieben habe, habe ich hier in Gruppen einen guten zu einem ähnlichen Thema gefunden. Klicken Sie auf den Link und lesen Sie, je mehr desto besser! Inhalt:

• Warum ist das notwendig?
• Was bringt das dem Entwickler?

Warum ist das notwendig?

Wenn der Code aus einer Klasse besteht, ist dies nicht wirklich notwendig. Wenn jedoch Klassen miteinander interagieren müssen und ihre Anzahl mehrere Dutzend übersteigt, ist es an der Zeit, über Design nachzudenken. Denken Sie zunächst die gesamte Struktur des Projekts von oben bis unten durch (von der maximalen Abstraktion bis zur Umsetzung). Wenn mehrere Personen an einem Projekt arbeiten, ist es sehr praktisch, sich zu einigen, die Interaktionsschnittstellen von Klassen zu beschreiben, diese Schnittstellen dann zu zerlegen und mit der Implementierung zu beginnen. Das Ergebnis ist eine gute Parallelität der Aufgaben; sie sind leicht aufzuteilen, weil Alle sind sich in allem einig, aber die Details interessieren niemanden.

Was bringt das dem Entwickler?

Der Entwickler benötigt keine Implementierung der Klasse. Das heißt, nachdem alle zugestimmt haben, nimmt er die Schnittstellen, die er benötigt, und nutzt sie. Die Implementierung wird ersetzt, wenn sie fertig ist. Lassen Sie mich Ihnen mein Beispiel zeigen, und dann reden wir weiter. Ich beschloss, ein kleines Registrierkassenprojekt zu schreiben. Sie hilft bei der Auswahl der Tickets, beim Verkauf, beim Geben und Nehmen von Geld bei der Bank und beim Geldwechsel für diejenigen, die in großer Zahl kommen. Also mein architektonischer Ausspruch: PS: Es besteht keine Notwendigkeit, eine Struktur zu kopieren und zu erstellen. Der Faulheit halber habe ich am Ende des Artikels ein Archiv mit Code angehängt ;) Struktur : Eine Reihe von Modellen:

package cashbox.model;

public enum Currency {
    USD,
    EUR,
    RUR
}

package cashbox.model;

public interface Direction {
    /**
     * @return город Wie цель направления, куда едем/летим/двигаемся
     */
    String getCity();
}

package cashbox.model;

/**
 * модель денег
 */
public interface Money {
    /**
     * @return тип валюты
     */
    Currency getCurrency();

    /**
     * @return сумма денег
     */
    long getAmount();
}

package cashbox.model;

public interface Ticket {
    /**
     * @return направление куда двигаемся
     */
    Direction getDirection();

    /**
     * @return цена билета
     */
    Money getPrice();

    /**
     * @return транспорт на котором передвигаемся
     */
    Transport getTransport();
}

package cashbox.model;

public interface Transport {
}

Ausnahmepaar:

package cashbox.exception;

public class NoSoMuchMoneyException extends RuntimeException {
}

package cashbox.exception;

import cashbox.model.Money;

public class NoSuchCurrencyException extends RuntimeException {
    private Money money;

    public NoSuchCurrencyException(Money money) {
        this.money = money;
    }

    public NoSuchCurrencyException(String message, Money money) {
        super(message);
        this.money = money;
    }

    public Money getMoney() {
        return money;
    }
}

Die Kasse ist der wichtigste Teil:

package cashbox;

import cashbox.exception.NoSoMuchMoneyException;
import cashbox.exception.NoSuchCurrencyException;
import cashbox.model.*;
import javafx.util.Pair;

import java.util.List;
import java.util.Map;

public interface CashBox {

    /**
     * @param direction направление билета
     * @return Стоимость проезда по видам транспорта
     */
    Map<Transport, Money> getPrice(Direction direction);

    /**
     * Продать билет
     * @param money деньги за билет
     * @return пару из билета и сдачи
     */
    Pair<Ticket, Money> sellTicket(Money money);

    /**
     * обмен валюты
     * @param moneyFrom валюта, которую передает клиент
     * @param currency валюта, которую клиент хочет получить, тут будет учитываться только тип валюты,
     *                 количество будет проигнорировано
     * @return Требуемая валюта
     * @throws NoSoMuchMoneyException если недостаточно денег в кассе для обмена
     * @throws NoSuchCurrencyException если нет такой валюты, отсутствующая валюта передается Wie атрибут
     */
    Money change(Money moneyFrom, Currency currency) throws NoSoMuchMoneyException, NoSuchCurrencyException;

    /**
     * Инкасация - отправить деньги в банк
     * @param money - сумма и валюта, можно передать несколько
     */
    void sendToBank(Money... money);

    /**
     * Запрос денег из банка
     * @param money - сумма и валюта необходимая кассе
     */
    void requestFromBank(Money... money);

    /**
     * Подбор билета.
     * В метод передается либо одно, либо другое, либо вместе.
     * Если оба атрибута null значит вызов некорректный
     * @param transport - желаемый транспорт
     * @param direction - желаемое направление
     * @return список подходящих билетов
     */
    List<Ticket> chooseBy(Transport transport, Direction direction);
}

Das erste, was einem unvorbereiteten Entwickler ins Auge fällt, ist javadoc. Obwohl sie einem ungeschulten Entwickler wahrscheinlich bekannt sind. Manche Leute sind manchmal faul, aber mein Code ist schon gut, auch ohne Dokument ;) Auch jetzt möchte ich über manche Dinge kein Dokument schreiben. Warum also dem Transport schreiben, dass es sich um einen Transport handelt? Lasst uns das für später aufheben! Ich habe versucht, in Dokumenten alles Notwendige zu beschreiben. Jetzt erkläre ich, warum es bequemer ist, Code auf diese Weise zu schreiben. Schauen Sie, jetzt kann ich Ihnen eine Schnittstelle geben CashBoxund Sie bitten, diese zu implementieren. Ist er nicht schwierig? Außerdem ist das erforderliche Verhalten in der Dokumentation beschrieben. Sie müssen nicht darauf warten, dass jemand Modelle oder ähnliches schreibt. Sie nehmen Schnittstellenmodelle und beginnen darauf basierend zu arbeiten. Jetzt programmieren Sie in Schnittstellen, herzlichen Glückwunsch. Und jetzt die Hauptsache. CashBoxIch kann Ihnen und jemand anderem die Aufgabe zur Implementierung geben , so dass wir 2 Implementierungen haben. Zum Beispiel Vorstadt- und internationale Fahrkartenschalter. Sie können parallel Code schreiben und jedes Teammitglied, das darauf basierenden Code schreibt, CashBoxkann bereits mit der Schnittstelle beginnen und darauf aufbauen. Es ist sehr bequem. Multitasking, zum Teufel damit. Link zum Code auf Google Drive -> hier